Re: [Patch 5/7] synchronous block I/O delays

[Shailabh Nagar <nagar@watson.ibm.com>]

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/