lkml.org 
[lkml]   [2006]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Patch 5/7] synchronous block I/O delays
    Andi Kleen wrote:

    >Shailabh Nagar <nagar@watson.ibm.com> writes:
    >
    >
    >
    >>delayacct-blkio.patch
    >>
    >>Record time spent by a task waiting for completion of
    >>userspace initiated synchronous block I/O. This can help
    >>determine the right I/O priority for the task.
    >>
    >>
    >
    >I think it's a good idea to have such a statistic by default.
    >
    >
    Besides the paths we're counting and the one's Arjan listed below, are
    there others
    you had in mind ?

    >Can you add a counter that is summed up in task_struct and reports
    >in /proc/*/stat so that it could be displayed by top?
    >
    >This way it would be useful even with "normal" user space.
    >
    >-Andi
    >

    Arjan van de Ven wrote:

    >this misses O_SYNC, msync(), and general throttling.
    >I get the feeling this is being measured at the wrong level
    >currently.... since the number of entry points that needs measuring at
    >the current level is hardly finite...
    >
    >

    Our intent was to get an idea of user-initiated sync block I/O because
    there is some expectation from user space that a higher I/O priority will
    result in lower delays for such I/O. General throttling writes wouldn't
    fit in
    this category though msync and O_SYNC would.

    Are there a lot of other paths you see ? I'll root around more but if you
    could just list a few more, it'll help.

    As for the level at which the counting is being done, the reason for
    choosing this one was to avoid counting time spent waiting for async I/O
    completion and also to keep the accounting simple (diff of two
    timestamps without
    modifying block I/O structures).

    To our usage model, async I/O is also not as useful to be counted since
    userspace has already
    taken steps to tolerate the latency and can do useful work (and not be
    "delayed").
    However, I would have liked to capture the time spent within
    sys_io_getevents
    when a timeout is specified, since there the user is again going to be
    delayed,
    but the mingling of block and network I/O events makes that more complex.


    Going further down the I/O processing stack than the current level would
    probably require more elaborate mechanisms to keep track of the submitter ?
    Or is there a better merging point for sync I/O that I'm missing ?

    Your comments would be welcome to improve this code...

    --Shailabh
    P.S. Sorry if merging the two responses violates any netiquette :-)

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-02-27 23:12    [W:4.181 / U:0.264 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site