Re: CFQ will be the new default IO scheduler - why?

Re: CFQ will be the new default IO scheduler - why?

[Al Boldi]

Justin Piszcz wrote:
> On Mon, 24 Jul 2006, Matthias Andree wrote:
> > On Sun, 23 Jul 2006, Paa Paa wrote:
> >> The default IO scheduler in 2.6.18 will be CFQ (Complete Fair Queuing)
> >> instead of AS (Anticipatory Scheduler) as described here:
> >> http://wiki.kernelnewbies.org/Linux_2_6_18. I tried to find (here, at
> >> lkml) the discussion about this change with no luck.
> >
> > That wiki document nicely shows the advantage of the scheduler, namely
> > that you have "ionice", which isn't possible for AS or Deadline
> > Schedulers - this allows the operating system to run processes like
> > updatedb with "nice I/O", meaning these hold when you're doing other
> > I/O.
>
> Should there be a default scheduler per filesystem?  As some filesystems
> may perform better/worse with one over another?

It's currently perDevice, and should probably be extended to perMount.

Thanks!

--
Al

Re: CFQ will be the new default IO scheduler - why?

[Arjan van de Ven]

> > Should there be a default scheduler per filesystem?  As some filesystems
> > may perform better/worse with one over another?
> 
> It's currently perDevice, and should probably be extended to perMount.

Hi,

per mount is going to be "not funny". I assume the situation you are
aiming for is the "3 partitions on a disk, each wants its own elevator".
The way the kernel currently works is that IO requests the filesystem
does are first flattened into an IO for the entire device (eg the
partition mapping is done) and THEN the IO scheduler gets involved to
schedule the IO on a per disk basis.
The 2.4 kernel did this the other way around, and it was really a bad
idea (no fairness, less optimal scheduling all around due to less
visibility into what the disk is really doing, several hardware
properties such as TCQ depth that affect scheduling IOs are truely per
disk not per partition etc etc)

So I don't think it's likely that per mount is really an option right
now..

Greetings,
   Arjan van de Ven

--
if you want to mail me at work, send mail to arjan (at) linux.intel.com

Re: CFQ will be the new default IO scheduler - why?

[Al Boldi]

Arjan van de Ven wrote:
> > > Should there be a default scheduler per filesystem?  As some
> > > filesystems may perform better/worse with one over another?
> >
> > It's currently perDevice, and should probably be extended to perMount.
>
> Hi,

Hi!

> per mount is going to be "not funny". I assume the situation you are
> aiming for is the "3 partitions on a disk, each wants its own elevator".
> The way the kernel currently works is that IO requests the filesystem
> does are first flattened into an IO for the entire device (eg the
> partition mapping is done) and THEN the IO scheduler gets involved to
> schedule the IO on a per disk basis.

IC.  That probably explains why concurrent io-procs have such a hard time 
getting through to the disk.  They probably just hang in the flatting phase, 
waiting for something to take care of their requests.

> The 2.4 kernel did this the other way around, and it was really a bad
> idea (no fairness, less optimal scheduling all around due to less
> visibility into what the disk is really doing, several hardware
> properties such as TCQ depth that affect scheduling IOs are truely per
> disk not per partition etc etc)
>
> So I don't think it's likely that per mount is really an option right
> now..

Probably true as it stands right now, but extending io-sched semantics to be 
filesystem aware in the "flattening/partition mapping" phase could improve 
performance a lot.

Thanks!

--
Al

Re: CFQ will be the new default IO scheduler - why?

[Arjan van de Ven]

Al Boldi wrote:
> Arjan van de Ven wrote:
>>>> Should there be a default scheduler per filesystem?  As some
>>>> filesystems may perform better/worse with one over another?
>>> It's currently perDevice, and should probably be extended to perMount.
>> Hi,
> 
> Hi!
> 
>> per mount is going to be "not funny". I assume the situation you are
>> aiming for is the "3 partitions on a disk, each wants its own elevator".
>> The way the kernel currently works is that IO requests the filesystem
>> does are first flattened into an IO for the entire device (eg the
>> partition mapping is done) and THEN the IO scheduler gets involved to
>> schedule the IO on a per disk basis.
> 
> IC.  That probably explains why concurrent io-procs have such a hard time 
> getting through to the disk.  They probably just hang in the flatting phase, 
> waiting for something to take care of their requests.
> 
flattening is just an addition in the cpu, that's just really boring and shouldn't be visible anywhere
performance wise

Re: CFQ will be the new default IO scheduler - why?

[Al Boldi]

Arjan van de Ven wrote:
> Al Boldi wrote:
> > Arjan van de Ven wrote:
> >>>> Should there be a default scheduler per filesystem?  As some
> >>>> filesystems may perform better/worse with one over another?
> >>>
> >>> It's currently perDevice, and should probably be extended to perMount.
> >>
> >> Hi,
> >
> > Hi!
> >
> >> per mount is going to be "not funny". I assume the situation you are
> >> aiming for is the "3 partitions on a disk, each wants its own
> >> elevator". The way the kernel currently works is that IO requests the
> >> filesystem does are first flattened into an IO for the entire device
> >> (eg the partition mapping is done) and THEN the IO scheduler gets
> >> involved to schedule the IO on a per disk basis.
> >
> > IC.  That probably explains why concurrent io-procs have such a hard
> > time getting through to the disk.  They probably just hang in the
> > flatting phase, waiting for something to take care of their requests.
>
> flattening is just an addition in the cpu, that's just really boring and
> shouldn't be visible anywhere performance wise

Try this on 2.6 and 2.4 respectively:
# cat /dev/hda > /dev/null
< switch to another vt >
< login >
< start timing >
< wait for shell >
< stop timing >
< wait for dcache to be gobbled by cat and repeat login as necessary >

On my system 2.4.31 (2sec) is at least twice as fast as 2.6.17 (4-10sec) 
depending on io-scheduler, with noop/deadline performing best, albeit a lot 
of noise (scrubbing the disk), and anti/cfq performing worst, albeit quieter 
(just hanging around).

Thanks!

--
Al

Re: CFQ will be the new default IO scheduler - why?

[Justin Piszcz]

On Mon, 24 Jul 2006, Matthias Andree wrote:

> On Sun, 23 Jul 2006, Paa Paa wrote:
>
>> The default IO scheduler in 2.6.18 will be CFQ (Complete Fair Queuing)
>> instead of AS (Anticipatory Scheduler) as described here:
>> http://wiki.kernelnewbies.org/Linux_2_6_18. I tried to find (here, at lkml)
>> the discussion about this change with no luck.
>
> That wiki document nicely shows the advantage of the scheduler, namely
> that you have "ionice", which isn't possible for AS or Deadline
> Schedulers - this allows the operating system to run processes like
> updatedb with "nice I/O", meaning these hold when you're doing other
> I/O.
>
> -- 
> Matthias Andree
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Should there be a default scheduler per filesystem?  As some filesystems 
may perform better/worse with one over another?

Justin.

Re: CFQ will be the new default IO scheduler - why?

[Matthias Andree]

On Sun, 23 Jul 2006, Paa Paa wrote:

> The default IO scheduler in 2.6.18 will be CFQ (Complete Fair Queuing) 
> instead of AS (Anticipatory Scheduler) as described here: 
> http://wiki.kernelnewbies.org/Linux_2_6_18. I tried to find (here, at lkml) 
> the discussion about this change with no luck.

That wiki document nicely shows the advantage of the scheduler, namely
that you have "ionice", which isn't possible for AS or Deadline
Schedulers - this allows the operating system to run processes like
updatedb with "nice I/O", meaning these hold when you're doing other
I/O.

-- 
Matthias Andree

CFQ will be the new default IO scheduler - why?

[Paa Paa]

The default IO scheduler in 2.6.18 will be CFQ (Complete Fair Queuing) 
instead of AS (Anticipatory Scheduler) as described here: 
http://wiki.kernelnewbies.org/Linux_2_6_18. I tried to find (here, at lkml) 
the discussion about this change with no luck.

What is the reason CFQ will be the new default? What advantages it has over 
AS performance and feature wise? Any links to relevant and recent 
benchmarks?

And if there is a recent discussion about this online, a link would be 
greatly appreciated.

Best regards,
Paapaa

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/