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:0.112 / U:2.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site