RE: [PATCH 0/7] Per-bdi writeback flusher threads

[Jos Houtman]

I tried the write-back branch from the 2.6-block tree.

And I can atleast confirm that it works, atleast in relation to the
writeback not keeping up when the device was congested before it wrote a
1024 pages. 

See: http://lkml.org/lkml/2009/3/22/83  for a bit more information.


But the second problem seen in that thread, a write-starve-read problem does
not seem to solved. In this problem the writes of the writeback algorithm
starve the ongoing reads, no matter what io-scheduler is picked.

For good measure I also applied the blk-latency patches on top of the
writeback branch, this did not improve anything. Nor did lowering
max_sectors_kb, as linus suggested in the IO latency thread.


As for a reproducible test-case: the simplest I could come up with was
modifying the fsync-tester not to fsync, but letting the normal writeback
handle it. And starting a separate process that tries to sequentially read a
file from the same device. The read performance drops to a bare minimum as
soon as the writeback algorithm kicks in.


Jos





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