diff options
| author | Andrew Morton <akpm@digeo.com> | 2003-02-05 16:56:31 -0800 |
|---|---|---|
| committer | Linus Torvalds <torvalds@home.transmeta.com> | 2003-02-05 16:56:31 -0800 |
| commit | 00c8e791cba1bb88db8a8fd73106c28fdbab5716 (patch) | |
| tree | d1242ea5923a8b6fba8b95c909b8670b260f261e /include | |
| parent | c5070032bb8db845535ac8c85d45884138a08a4f (diff) | |
[PATCH] self-unplugging request queues
The patch teaches a queue to unplug itself:
a) if is has four requests OR
b) if it has had plugged requests for 3 milliseconds.
These numbers may need to be tuned, although doing so doesn't seem to
make much difference. 10 msecs works OK, so HZ=100 machines will be
fine.
Instrumentation shows that about 5-10% of requests were started due to
the three millisecond timeout (during a kernel compile). That's
somewhat significant. It means that the kernel is leaving stuff in the
queue, plugged, for too long. This testing was with a uniprocessor
preemptible kernel, which is particularly vulnerable to unplug latency
(submit some IO, get preempted before the unplug).
This patch permits the removal of a lot of rather lame unplugging in
page reclaim and in the writeback code, which kicks the queues
(globally!) every four megabytes to get writeback underway.
This patch doesn't use blk_run_queues(). It is able to kick just the
particular queue.
The patch is not expected to make much difference really, except for
AIO. AIO needs a blk_run_queues() in its io_submit() call. For each
request. This means that AIO has to disable plugging altogether,
unless something like this patch does it for it. It means that AIO
will unplug *all* queues in the machine for every io_submit(). Even
against a socket!
This patch was tested by disabling blk_run_queues() completely. The
system ran OK.
The 3 milliseconds may be too long. It's OK for the heavy writeback
code, but AIO may want less. Or maybe AIO really wants zero (ie:
disable plugging). If that is so, we need new code paths by which AIO
can communicate the "immediate unplug" information - a global unplug is
not good.
To minimise unplug latency due to user CPU load, this patch gives keventd
`nice -10'. This is of course completely arbitrary. Really, I think keventd
should be SCHED_RR/MAX_RT_PRIO-1, as it has been in -aa kernels for ages.
Diffstat (limited to 'include')
| -rw-r--r-- | include/linux/blkdev.h | 10 |
1 files changed, 10 insertions, 0 deletions
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h index c599ea36233b..82766b7e60b0 100644 --- a/include/linux/blkdev.h +++ b/include/linux/blkdev.h @@ -4,6 +4,8 @@ #include <linux/major.h> #include <linux/genhd.h> #include <linux/list.h> +#include <linux/timer.h> +#include <linux/workqueue.h> #include <linux/pagemap.h> #include <linux/backing-dev.h> #include <linux/wait.h> @@ -188,6 +190,14 @@ struct request_queue unplug_fn *unplug_fn; merge_bvec_fn *merge_bvec_fn; + /* + * Auto-unplugging state + */ + struct timer_list unplug_timer; + int unplug_thresh; /* After this many requests */ + unsigned long unplug_delay; /* After this many jiffies */ + struct work_struct unplug_work; + struct backing_dev_info backing_dev_info; /* |
