* Re: CFQ will be the new default IO scheduler - why?
@ 2006-07-24 15:57 Al Boldi
2006-07-24 16:33 ` Arjan van de Ven
0 siblings, 1 reply; 8+ messages in thread
From: Al Boldi @ 2006-07-24 15:57 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-fsdevel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: CFQ will be the new default IO scheduler - why?
2006-07-24 15:57 CFQ will be the new default IO scheduler - why? Al Boldi
@ 2006-07-24 16:33 ` Arjan van de Ven
2006-07-25 4:56 ` Al Boldi
0 siblings, 1 reply; 8+ messages in thread
From: Arjan van de Ven @ 2006-07-24 16:33 UTC (permalink / raw)
To: Al Boldi; +Cc: linux-kernel, linux-fsdevel
> > 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: CFQ will be the new default IO scheduler - why?
2006-07-24 16:33 ` Arjan van de Ven
@ 2006-07-25 4:56 ` Al Boldi
2006-07-25 4:59 ` Arjan van de Ven
0 siblings, 1 reply; 8+ messages in thread
From: Al Boldi @ 2006-07-25 4:56 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: linux-kernel, linux-fsdevel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: CFQ will be the new default IO scheduler - why?
2006-07-25 4:56 ` Al Boldi
@ 2006-07-25 4:59 ` Arjan van de Ven
2006-07-25 18:27 ` Al Boldi
0 siblings, 1 reply; 8+ messages in thread
From: Arjan van de Ven @ 2006-07-25 4:59 UTC (permalink / raw)
To: Al Boldi; +Cc: Arjan van de Ven, linux-kernel, linux-fsdevel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: CFQ will be the new default IO scheduler - why?
2006-07-25 4:59 ` Arjan van de Ven
@ 2006-07-25 18:27 ` Al Boldi
0 siblings, 0 replies; 8+ messages in thread
From: Al Boldi @ 2006-07-25 18:27 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: linux-kernel, linux-fsdevel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* CFQ will be the new default IO scheduler - why?
@ 2006-07-23 19:08 Paa Paa
2006-07-24 8:29 ` Matthias Andree
0 siblings, 1 reply; 8+ messages in thread
From: Paa Paa @ 2006-07-23 19:08 UTC (permalink / raw)
To: linux-kernel
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/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: CFQ will be the new default IO scheduler - why?
2006-07-23 19:08 Paa Paa
@ 2006-07-24 8:29 ` Matthias Andree
2006-07-24 12:41 ` Justin Piszcz
0 siblings, 1 reply; 8+ messages in thread
From: Matthias Andree @ 2006-07-24 8:29 UTC (permalink / raw)
To: Paa Paa; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: CFQ will be the new default IO scheduler - why?
2006-07-24 8:29 ` Matthias Andree
@ 2006-07-24 12:41 ` Justin Piszcz
0 siblings, 0 replies; 8+ messages in thread
From: Justin Piszcz @ 2006-07-24 12:41 UTC (permalink / raw)
To: Matthias Andree; +Cc: Paa Paa, linux-kernel
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2006-07-25 18:25 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-07-24 15:57 CFQ will be the new default IO scheduler - why? Al Boldi
2006-07-24 16:33 ` Arjan van de Ven
2006-07-25 4:56 ` Al Boldi
2006-07-25 4:59 ` Arjan van de Ven
2006-07-25 18:27 ` Al Boldi
-- strict thread matches above, loose matches on Subject: below --
2006-07-23 19:08 Paa Paa
2006-07-24 8:29 ` Matthias Andree
2006-07-24 12:41 ` Justin Piszcz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).