Re: Time sliced CFQ io scheduler

[Jens Axboe]

On Fri, Dec 03 2004, Prakash K. Cheemplavam wrote:
> Jens Axboe schrieb:
> >On Fri, Dec 03 2004, Andrew Morton wrote:
> >
> >>"Prakash K. Cheemplavam" <prakashkc@xxxxxx> wrote:
> >>
> >>Is this a parallel IDE system?  SATA?  SCSI?  If the latter, what driver
> >>and what is the TCQ depth?
> >
> >
> >Yeah, that would be interesting to know. Or of the device is on dm or
> >raid. And what filesystem is being used?
> 
> It is ext3. (The writing-makes-reading-starve problem happen on reiserfs 
> as well. ext2 is not so bad and xfs behaves best, ie my email client 
> doesn't get unuasable with my earlier tests, but "only" very slow. But 
> then I only wrote down 2gb and nothing continuesly.)

It's impossible to give really good results on ext3/reiser in my
experience, because reads often need to generate a write as well. What
could work is if a reader got PF_SYNCWRITE set while that happens.

Or even better would be to kill that horrible PF_SYNCWRITE hack (Andrew,
how could you!) and really have the fs use the proper WRITE_SYNC
instead.

> >So Prakash, please try the same test with those settings:
> >
> ># cd /sys/block/<dev>/queue/iosched
> ># echo 6 > idle
> ># echo 150 > slice
> >
> >These are the first I tried, there may be better settings. If you have
> >your filesystem on dm/raid, you probably want to do the above for each
> >device the dm/raid is composed of.
> 
> Yeas, I have linux raid (testing md1). Have appield both settings on 
> both drives and got a interesting new pattern: Now it alternates. My 
> email client is still not usale while writing though...

Funky. It looks like another case of the io scheduler being at the wrong
place - if raid sends dependent reads to different drives, it screws up
the io scheduling. The right way to fix that would be to io scheduler
before raid (reverse of what we do now), but that is a lot of work. A
hack would be to try and tie processes to one md component for periods
of time, sort of like cfq slicing.

-- 
Jens Axboe

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