lkml.org 
[lkml]   [2003]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [SHED][IO-SHED] Are we missing the big picture?
From
Date
On Fri, 2003-08-01 at 14:32, Jens Axboe wrote:
> On Fri, Aug 01 2003, Ian Kumlien wrote:
> > On Fri, 2003-08-01 at 11:00, Ihar "Philips" Filipau wrote:
> > > Am I right - judging from your posting - that we finally reached
> > > moment than Linux will have network-like queueing disciplines for disks
> > > and CPUs?
> >
> > CPU's? well, we do have a nice sheduler but i wouldn't say network-like
> > queuing.
> >
> > > In any way, CPU/disk throughput just another types of limited resource.
> > > It would be nice to be able to manage it - who gets more, who gets
> > > less. CPU/disk schedulers by manageability are far behind network.
> > > IMHO must have for servers.
> >
> > Yes, but, thats not what I'm saying.
> >
> > CFQ as it apparently was called, builds a queue list when the disk is
>
> I coined that phrase as a variant of SFQ, with C being Complete.

Yeah, i remember that now, but late at night your mind can be playing
tricks on you =P

> > under load. So you get really fast data access if there is no load, and
> > a common queue when there is load. The common queue is the bad thing
> > about CFQ, imagine putting AS there instead... This would mean fast data
> > access on unloaded systems, better throughput on loaded systems and
> > prioritization features could hook right in since AS would only be used
> > during load. IE, you can add all kinds of patches that only matters
> > during heavy load.
>
> I dunno where you get this from, but you seem to have a misguide picture
> of how io schedulers work in Linux. AS works like deadline, but adds
> anticipation. This means you try to anticipate whether a process will
> issue a nearby read soon, and if so stall the disk head. deadline itself
> has a single queue for merging/sorting, and a single queue as a deadline
> fifo (for each data direction, read and write).

Hummm, from what i gathered from reading this list it has a 'standoff
period' (like you said after getting data but also) before it initiates
a read... And afair, CFQ did just about 'nothing' when the disk wasn't
under 'load'.

I also thought that deadline didn't merge and sort on the same level as
AS.

> Where CFQ differs is that it maintains such a backend system for each
> "class" (user, could be a task grouping of some sort too), with a small
> front end (class independent scheduler is used in some contexts) to
> select which class we do IO from. The old design just round-robined
> between all "busy" tasks, with some heuristics to minimize seeks.

Ahhh

> So for a single task, deadline and CFQ works the same basically. AS
> differs because of the anticipation of course.

Yes, but...
I was more referring to the stalls in AS (the waits). If one could
eliminate them and just enable AS when the disk is loaded... Then we
could add all the 'bonus on wait' and or process priorities being
honored etc, atm, it just feels like overhead, it might be small but
still.

And, if sfq would build up one queue and feed it to AS, don't you think
there would be a gain? Esp in small reads when not loaded and scattered
small reads... Aswell as during heavy load?

> > > > I liked Jens Axobe's 'CBQ' alike implementation (based on the idea of
> > > > Andrea A. (afair i have the names right) since it does the most
>
> Nope, it's Axboe :)

Argh!
/me fires himself =)

--
Ian Kumlien <pomac@vapor.com>
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-03-22 13:47    [W:0.039 / U:5.832 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site