Re: io performance...

From: Jeff V. Merkey
Date: Tue Jan 17 2006 - 16:02:40 EST


Jens Axboe wrote:

On Mon, Jan 16 2006, Jeff V. Merkey wrote:


Max Waterman wrote:



Hi,

I've been referred to this list from the linux-raid list.

I've been playing with a RAID system, trying to obtain best bandwidth


from it.


I've noticed that I consistently get better (read) numbers from kernel 2.6.8
than from later kernels.


To open the bottlenecks, the following works well. Jens will shoot me for recommending this,
but it works well. 2.6.9 so far has the highest numbers with this fix. You can manually putz
around with these numbers, but they are an artificial constraint if you are using RAID technology
that caches ad elevators requests and consolidates them.


Jeff







diff -Naur ./include/linux/blkdev.h ../linux-2.6.9/./include/linux/blkdev.h
--- ./include/linux/blkdev.h 2004-10-18 15:53:43.000000000 -0600
+++ ../linux-2.6.9/./include/linux/blkdev.h 2005-12-06 09:54:46.000000000 -0700
@@ -23,8 +23,10 @@
typedef struct elevator_s elevator_t;
struct request_pm_state;

-#define BLKDEV_MIN_RQ 4
-#define BLKDEV_MAX_RQ 128 /* Default maximum */
+//#define BLKDEV_MIN_RQ 4
+//#define BLKDEV_MAX_RQ 128 /* Default maximum */
+#define BLKDEV_MIN_RQ 4096
+#define BLKDEV_MAX_RQ 8192 /* Default maximum */



Yeah I could shoot you. However I'm more interested in why this is
necessary, eg I'd like to see some numbers from you comparing:

- The stock settings
- Doing
# echo 8192 > /sys/block/<dev>/queue/nr_requests
for each drive you are accessing.
- The kernel with your patch.

If #2 and #3 don't provide very similar profiles/scores, then we have
something to look at.

The BLKDEV_MIN_RQ increase is just silly and wastes a huge amount of
memory for no good reason.



Yep. I build it into the kernel to save the trouble of sending it to proc. Jens recommendation
will work just fine. It has the same affect of increasing the max requests outstanding.

Jeff
-
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/