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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Andi Kleen wrote:

Shailabh Nagar <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux