archive mirror
 help / color / mirror / Atom feed
From: Ian Kumlien <>
To: Jens Axboe <>
Cc: Ihar Philips Filipau <>,
	Linux Kernel Mailing List <>
Subject: Re: [SHED][IO-SHED] Are we missing the big picture?
Date: 01 Aug 2003 15:01:42 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

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

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


> 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

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 :)

/me fires himself =)

Ian Kumlien <>

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

  reply	other threads:[~2003-08-01 13:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2003-08-01  9:00 ` [SHED][IO-SHED] Are we missing the big picture? Ihar "Philips" Filipau
2003-08-01 12:23   ` Ian Kumlien
2003-08-01 12:32     ` Jens Axboe
2003-08-01 13:01       ` Ian Kumlien [this message]
2003-08-01  0:32 Ian Kumlien
2003-08-01  6:27 ` Nick Piggin
2003-08-01 12:18   ` Ian Kumlien
2003-08-02  1:49     ` Nick Piggin
2003-08-02  2:07       ` Ian Kumlien

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).