Re: RAID 5 performance issue.

2007-10-06 Thread Justin Piszcz
On Fri, 5 Oct 2007, Dean S. Messing wrote: Brendan Conoboy wrote: snip Is the onboard SATA controller real SATA or just an ATA-SATA converter? If the latter, you're going to have trouble getting faster performance than any one disk can give you at a time. The output of 'lspci' should tell

Re: RAID 5 performance issue.

2007-10-06 Thread Andrew Clayton
On Wed, 3 Oct 2007 12:48:27 -0400 (EDT), Justin Piszcz wrote: Also if it is software raid, when you make the XFS filesyste, on it, it sets up a proper (and tuned) sunit/swidth, so why would you want to change that? Oh I didn't, the sunit and swidth were set automatically. Do they look sane?.

Re: RAID 5 performance issue.

2007-10-06 Thread Justin Piszcz
On Wed, 3 Oct 2007, Andrew Clayton wrote: On Wed, 3 Oct 2007 12:48:27 -0400 (EDT), Justin Piszcz wrote: Also if it is software raid, when you make the XFS filesyste, on it, it sets up a proper (and tuned) sunit/swidth, so why would you want to change that? Oh I didn't, the sunit and

Re: RAID 5 performance issue.

2007-10-06 Thread Justin Piszcz
On Sat, 6 Oct 2007, Justin Piszcz wrote: On Wed, 3 Oct 2007, Andrew Clayton wrote: On Wed, 3 Oct 2007 12:48:27 -0400 (EDT), Justin Piszcz wrote: Also if it is software raid, when you make the XFS filesyste, on it, it sets up a proper (and tuned) sunit/swidth, so why would you want to

[PATCH -mm 0/4] raid5: stripe_queue (+20% to +90% write performance)

2007-10-06 Thread Dan Williams
Neil, Here is the latest spin of the 'stripe_queue' implementation. Thanks to raid6+bitmap testing done by Mr. James W. Laferriere there have been several cleanups and fixes since the last release. Also, the changes are now spread over 4 patches to isolate one conceptual change per patch. The

[PATCH -mm 1/4] raid5: add the stripe_queue object for tracking raid io requests (rev3)

2007-10-06 Thread Dan Williams
The raid5 stripe cache object, struct stripe_head, serves two purposes: 1/ front-end: queuing incoming requests 2/ back-end: transitioning requests through the cache state machine to the backing devices The problem with this model is that queuing decisions are directly

[PATCH -mm 2/4] raid5: split allocation of stripe_heads and stripe_queues

2007-10-06 Thread Dan Williams
Provide separate routines for allocating stripe_head and stripe_queue objects and introduce 'io_weight' bitmaps to struct stripe_queue. The io_weight bitmaps add an efficient way to determine what is pending in a stripe_queue using 'hweight' in comparison to a 'for' loop. Tested-by: Mr. James W.

[PATCH -mm 3/4] raid5: convert add_stripe_bio to add_queue_bio

2007-10-06 Thread Dan Williams
The stripe_queue object collects i/o requests before they are handled by the stripe-cache (via the stripe_head object). add_stripe_bio currently looks at the state of the stripe-cache to implement bitmap support, reimplement this using stripe_queue attributes. Introduce the

[PATCH -mm 4/4] raid5: use stripe_queues to prioritize the most deserving requests (rev7)

2007-10-06 Thread Dan Williams
Overview: Taking advantage of the stripe_queue/stripe_head separation, this patch implements a queue in front of the stripe cache. A stripe_queue pool accepts incoming requests. As requests are attached, the weight of the queue object is updated. A workqueue (raid456_cache_arbiter) is

Re: [PATCH -mm 0/4] raid5: stripe_queue (+20% to +90% write performance)

2007-10-06 Thread Justin Piszcz
On Sat, 6 Oct 2007, Dan Williams wrote: Neil, Here is the latest spin of the 'stripe_queue' implementation. Thanks to raid6+bitmap testing done by Mr. James W. Laferriere there have been several cleanups and fixes since the last release. Also, the changes are now spread over 4 patches to