Messages in this thread | | | Date | Thu, 30 Mar 2006 10:21:24 -0500 | From | Shailabh Nagar <> | Subject | Re: [Patch 2/8] Block I/O, swapin delays |
| |
Andrew Morton wrote:
>Shailabh Nagar <nagar@watson.ibm.com> wrote: > > >>delayacct-blkio-swapin.patch >> >>Collect per-task block I/O delay statistics. >> >>Unlike earlier iterations of the delay accounting >>patches, now delays are only collected for the actual >>I/O waits rather than try and cover the delays seen in >>I/O submission paths. >> >>Account separately for block I/O delays >>incurred as a result of swapin page faults whose >>frequency can be affected by the task/process' rss limit. >>Hence swapin delays can act as feedback for rss limit changes >>independent of I/O priority changes. >> >>.. >> >>+#define PF_SWAPIN 0x02000000 /* I am doing a swap in */ >> >> >> > >Is there really no sane alternative to doing it this way? > >
I'm not sure there is. This goes back to what is really being measured as "block I/O delay".
Earlier iterations of the code tried to measure total block I/O delay including I/O submission and the wait for completion: http://www.uwsg.indiana.edu/hypermail/linux/kernel/0602.3/0905.html In that design, the swapin delay was being measured as time spent in the do_swap_page function: http://www.uwsg.indiana.edu/hypermail/linux/kernel/0602.3/0906.html
However, Arjan pointed out the difficulties in trying to account for all I/O submission paths so we reverted to measuring just the block I/O wait time within io_schedule/io_schedule_timeout.
Since these functions will be called as a result of do_swap_page, the only way to distinguish a block I/O being done for a swapin vs. others was to mark the task struct in some way and task->flags seemed like a convenient way to do it.
We could easily introduce and use a separate flag variable in the delay accounting structure itself if using up another bit of task->flags is a concern ?
Or do you have doubts about the methodology of using a flag itself ? Don't see any other lightweight way of doing this.
--Shailabh
- 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/
| |