[RFC][Patch 0/4] Per-task delay accounting

From: Shailabh Nagar
Date: Mon Nov 14 2005 - 22:30:33 EST


Here is a set of patches that adds per-task delay accounting to
Linux. In this context, delays is the time spent by a task
waiting for some resource to become available. Currently the patches
record (or make available) the following delays:

CPU delay: time spent on runqueue waiting for a CPU to run on
Block I/O delay: waiting for block I/O to complete (including any
wait for queueing the request)
Page fault delay: waiting for page faults (major & minor) to get
completed


Having this information allows one to adjust the priorities (cpu, io)
and rss limits of a task. e.g. if task A is spending too much time
waiting for block I/O to complete compared to task B, bumping up
A's I/O priority relative to that of B might help.This isn't particularly
useful if one always want A to get more I/O bandwidth than B. But if one
is interested in dynamically adjusting priorities, delay statistics
complete the feedback loop.

The statistics are collected by simple timestamping and recording of
intervals in the task_struct. The cpu stats are already being collected
by the schedstats so no additional code is needed in the hot path of a
context switch.

They are made available through a connector interface which allows
- stats for a given <pid> to be obtained in response to a command
which specifies the <pid>. The need for dynamically obtaining delay
stats is the reason why piggybacking delay stats onto BSD process
accounting wasn't considered.
- stats for exiting tasks to be sent to userspace listeners. This can
be useful for collecting statistics by any kind of grouping done by
the userspace agent. Such groupings (banks/process aggregates/classes)
have been proposed by different projects.

Comments on the patches are requested.

--Shailabh


Series

delayacct-init.patch
delayacct-blkio.patch
delayacct-pgflt.patch
delayacct-connector.patch


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