> Can you try the patch below (made against 2.2.2-pre2)? The key is to
> recognise that when we wake up bdflush, we need to take into account how
> many dirty buffers there are; but when we decide whether or not to wait
> for the bdflush pass to complete, it is BUF_LOCKED, not BUF_DIRTY,
> buffers which are important. If we don't wait for bdflush once
> BUF_LOCKED grows too high, then we will simply continue to create more
> locked IO buffers until the request queues are completely saturated.
>
> For low memory configurations, triggering the flush purely on the
> percentage of dirty buffers makes no sense at all, so the patch also
> starts a wakeup when the total locked+dirty memory exceeds a certain
> threshold (currently 15% of memory).
>
> The patch also includes the previously posted code to allow both sync
> and bdflush to refile unlocked buffers on the locked list back onto the
> clean list, to tidy up after async IO.
>
> Only with all three of these items in place can I sustain decent
> performance on a 16MB box while doing a background heavy
> file/block-device write, as well as on a large 64MB configuration.
I tested Stephen's patch but performance of a compile run which normally
takes 20s dropped to nearly 3 minutes in the worst case and 1:10 minutes
average!!!
Went back to my quick refile_buffer patch (in fs/buffer.c), which takes
care of 5% free buffers:
- if (nr_buffers_type[BUF_DIRTY] > too_many)
- wakeup_bdflush(0);
+ if (nr_buffers_type[BUF_DIRTY] > too_many ||
+ nr_buffers - nr_buffers_type[BUF_DIRTY] -
+ nr_buffers_type[BUF_LOCKED]
+ < nr_buffers_type[BUF_DIRTY] / 20)
+ wakeup_bdflush(1);
Performance is _much_ better with it.
The test compile needs 58s in the worst case and 27s average!
All test runs done multiple times while "dd if=/dev/zero of=/dev/v/l bs=1024k"
on a 13G device was running.
Please give it a try.
Heinz
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Systemmanagement C/S Deutsche Telekom AG Entwicklungszentrum Darmstadt Heinz Mauelshagen Otto-Roehm-Strasse 71c Senior Systems Engineer Postfach 10 05 41 64205 Darmstadt mge@ez-darmstadt.telekom.de Germany +49 6151 886-425 FAX-386 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/