archive mirror
 help / color / mirror / Atom feed
From: Nick Piggin <>
To: Ian Kumlien <>
Subject: Re: [SHED][IO-SHED] Are we missing the big picture?
Date: Sat, 02 Aug 2003 11:49:24 +1000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Ian Kumlien wrote:

>On Fri, 2003-08-01 at 08:27, Nick Piggin wrote:
>>Ian Kumlien wrote:
>>>Hi all,
>>>I have been following the sheduler and interactivity discussions closely
>>>but via the archive, So i might be behind etc...
>>>[Note: sorry if i sound like mr.know-it-all etc, just trying to get a
>>>point across]
>>>Anyways, i think that the AS discussions that i have seen has missed
>>>some points. Getting the processes priority in AS is one thing, but fist
>>>of all i think there should be a stand off layer. Let me explain:
>>>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
>>>important thing... which is *nothing* when there is no load (ie, pass
>>>AS might be/is the best damn io sheduler for loaded machines but when
>>>there is no load, it's overhead. So in my opinion there should be
>>>something that first warrants the usage of AS before it's actually
>>>And, if it's only engaged during high load, additions like basing the
>>>requests priority on the process/tasks priority would make total sense,
>>>adding the 'wakeup on wait' or what it was would also make total
>>>sense... But how many of your machines uses the disk 100% of the time?
>>>(in the real world... )
>>>I don't know how 'CBQ' was implemented but any 'we are under load now'
>>>trigger would do it for me.
>>>Please see to it that my CC is included in any discussions =)
>>>PS. Or was it a version of SFQ? in that case s/CBQ/SFQ/g
>>To start with its CFQ. Also could you clarify what you mean by
>>load and what you mean by CFQ doing nothing, and why AS is overhead
>>in the no load case. I can't really follow what you are saying.
>CFQ passes the req's on directly until there is enough load... In the
>load case it builds queues. Just like SFQ (but sfq can drop packets

What do you mean? CFQ merges and sorts requests, and it services
each process in a round robin manner. I don't have the CFQ code
at hand, but I don't think it does anything different in the
"load" case.

>This way, we wouldn't have the initial
>'can-we-merge-this-with-other-data-coming' delay when not needed.

No that is what queue plugging can be used for.

>If as could be attached to the 'queue build up' then AS would only be
>doing what it's good at, throughput and minimizing head movements.

No, AS does only try to do what it is good at. As complex as it
is, its meant to be almost as simple as possible.

>Also patches that move prioritized data (data for processes with high
>pri) would fit right in there since you'd only be doing it during actual
>(note: load as in disk load)

I'm sorry but I'm having trouble working out what you are trying to say.
The disk gets its work in the form of a request. Linux keeps a queue of
outstanding requests for each disk. The IO schedulers are a layer between
the disk (driver) and the request queue. They get to choose the next
request that goes to the disk. AS is only set apart because it sometimes
chooses not to send a request at all even if there are some available.

Now what do you mean by disk load? And actual load? I can imagine that
if there are no requests you would say there is no load on the disk. If
there is 1 request there must be some actual load? Maybe you mean more
than 1 process with outstanding requests?

  reply	other threads:[~2003-08-02  1:49 UTC|newest]

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