Are we missing the big picture?
A message that is not in the archive (sent off-list or not yet received): [email protected]
Am I right - judging from your posting - that we finally reached
moment than Linux will have network-like queueing disciplines for disks and CPUs?
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.
Quoted 37 lines · Ian Kumlien
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 DS.
Quoted 3 lines · Ihar "Philips" Filipau
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.
Quoted 4 lines
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 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.
(note: load is only diskload)
Quoted 38 lines
Quoted 37 lines · Ian Kumlien
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 DS.
Signature · 1 line
Ian Kumlien <[email protected]>
Quoted 8 lines · Ian Kumlien
Quoted 3 lines · Ihar "Philips" Filipau
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.
Quoted 8 lines
Quoted 4 lines
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.
Quoted 7 lines
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).
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.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
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 :)
Signature · 1 line
Jens Axboe
Quoted 14 lines · Jens Axboe
Quoted 13 lines · Ian Kumlien
Quoted 3 lines · Ihar "Philips" Filipau
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.
Quoted 4 lines
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.
Quoted 5 lines
Quoted 3 lines
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
Quoted 8 lines
Quoted 7 lines
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.
Quoted 6 lines
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.
Quoted 5 lines
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
Quoted 2 lines
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?
Quoted 4 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
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 =)
Signature · 1 line
Ian Kumlien <[email protected]>