lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 23 Oct 2008 18:13:37 +0200
From:	Miquel van Smoorenburg <>
To:	Jens Axboe <>
Subject: [PATCH] elevator.c: prevent flushing small requests to device

While tracing I/O patterns with blktrace (a great tool) a few
weeks ago I identified a minor issue in elevator.c

[PATCH] elevator.c: prevent flushing small requests to device

When elv_insert() is called to insert a new request, and the
device is plugged,  bit of code at the end of the function
will unplug the device if the number of pending requests >= q->unplug_thresh.

This means the current request is also sent to the device immidiately
while it is potentially mergeable with the next request. This has been
observed when a lot of small sequential requests are made.

By unplugging the device before we add the new request to the
queue this can be prevented.

Signed-off-by: Miquel van Smoorenburg <>

diff -ruN linux- linux-
--- linux-	2008-09-08 19:40:20.000000000 +0200
+++ linux-	2008-10-23 00:33:21.000000000 +0200
@@ -602,6 +602,20 @@
+		/*
+		 * If we're going to unplug the device, do it now before
+		 * we put a potentially small and mergeable new
+		 * request on the queue, instead of just after it.
+		 */
+		if (blk_queue_plugged(q)) {
+			int nrq = q->rq.count[READ] + q->rq.count[WRITE]
+				- q->in_flight;
+			if (nrq >= q->unplug_thresh)
+				__generic_unplug_device(q);
+			if (elv_queue_empty(q))
+				blk_plug_device(q);
+			unplug_it = 0;
+		}
 		rq->cmd_flags |= REQ_SORTED;
 		if (rq_mergeable(rq)) {
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists