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 08:27, Nick Piggin wrote:
> Ian Kumlien wrote:
>
> >Hi all,
> >
> >I have been following the sheduler and interactivity discussions closely
> >but via the marc.theaimsgroup.com archive, So i might be behind etc...
> >=P
> >
> >[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
> >trough).
> >
> >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
> >engaged.
> >
> >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
afair).

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

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.

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

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