Interesting observation on Reiser4 flush delays and IO scheduler

Interesting observation on Reiser4 flush delays and IO scheduler

[Zan Lynx]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

On my laptop while running heavy disk read/write loads, I have
discovered that the deadline IO scheduler gives me a much better "feel"
and much shorter (and fewer) system freezes.  This is as compared to the
CFQ scheduler.

I'm not sure why this is yet.  A rough guess is that Reiser4's atom
merging, etc, is not preserving the data CFQ needs to time slice and
prioritize disk IO.  But I don't have any evidence for this guess.  Is
it plausible?

Something to think about.
-- 
Zan Lynx <zlynx@acm.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Interesting observation on Reiser4 flush delays and IO scheduler

[Zan Lynx]

[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

On Thu, 2007-08-02 at 14:28 -0600, Zan Lynx wrote:
> On my laptop while running heavy disk read/write loads, I have
> discovered that the deadline IO scheduler gives me a much better "feel"
> and much shorter (and fewer) system freezes.  This is as compared to the
> CFQ scheduler.

Something else I found today.  I'm back to the CFQ scheduler.  Deadline
was better in the heavy write-out situation, but not so good at reading.

It appears nr_requests was too low at the default of 128.  I have bumped
it to 1024.  Watching iostat's avgqu-sz field during writeout, I see it
hit over 450 now.  Pauses in things like music playback are much
reduced.

My theory is that an atom writeout stalls and blocks read requests if it
can't stuff the whole thing into the disk queue.

If that's true, it'd almost be nice to have a printk "stall warning" or
just have Reiser4 shove nr_requests up automatically until the queue can
hold a complete atom write.

I'm probably wrong with my theory, but I hope the nr_requests suggestion
can help other's with lag problems.
-- 
Zan Lynx <zlynx@acm.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]