On Wed, Oct 10, 2012 at 11:44 AM, Claudio Freire <klaussfreire@gmail.com> wrote:
> On Wed, Oct 10, 2012 at 9:52 AM, Shaun Thomas <sthomas@optionshouse.com> wrote:
>> On 10/09/2012 06:30 PM, Craig James wrote:
>>
>>> ra:8192 walb:1M ra:256 walb:1M ra:256 walb:256kB
>>> ---------------- ---------------- -----------------
>>> -c -t Run1 Run2 Run3 Run4 Run5 Run6 Run7 Run8 Run9
>>> 40 2500 4261 3722 4243 9286 9240 5712 9310 8530 8872
>>> 50 2000 4138 4399 3865 9213 9351 9578 8011 7651 8362
>>
...
> But really interesting numbers in any case. It these results are on
> the level, then maybe the kernel's read-ahead algorithm isn't as
> fool-proof as we thought? Gotta read the source. BRB
So, I've been digging.
Newer kernels (above 2.6.23) have a new read-ahead algorithm, called
the "on-demand" read ahead. Benchmarks on this new code[0] suggest
there is a penalty for random writes that wasn't there before. This
penalty is small in the benchmarks (less than 10% in all cases), but I
would imagine the issue would be amplified in the case of a kernel
with a misconfigured bg_writer (this case, IIRC).
This makes sense, in fact. Back when I tested the 8MB read-ahead on my
server, it was using 2.6.18. Now, 2.6.23 is in fact rather old, so
those benchmarks may no longer be relevant. There are tons of commits
since then[1], though only one pertaining writes from what I can tell.
However, I'm inclined to blame the bg_writer. How about tweaking the
dirty_background_ratio and dirty_ratio and re-trying?
[0] http://lwn.net/Articles/235181/
[1] https://github.com/torvalds/linux/commits/f5a246eab9a268f51ba8189ea5b098a1bfff200e/mm/readahead.c?page=1
