I've no idea what both of you are talking about.

How can giving people the freedom of choice be in any way counter-productive?


Thanks!

--
Al

-

[ message continues ]

The short translation of my message for you is "Linus, please don't
LART me too hard."



This sort of concern is too subjective for me to have an opinion on it.
My preferred sphere of operation is the Manichean domain of faster vs.
slower, functionality vs. non-functionality, and the like. For me, such
design concerns are like the need for a kernel to format pagetables so
the x86 MMU decodes what was intended, or for a compiler to emit valid
assembly instructions, or for a programmer to write C the compiler
won't reject with parse errors. If Linus, akpm, et al object to the
design, then invalid output was produced. Please refer to Linus, akpm,
et al for these sorts of design concerns.


-- wli
-

[ message continues ]

Sure, but I think, even from a technical point of view, competition is a good 
thing to have.  Pluggable schedulers give us this kind of competition, that 

Point taken.


What about PlugSched?


Thanks!

--
Al

-

[ message continues ]

from what I understood, there is a performance loss in plugsched
schedulers because they have to share code....

even if pluggable schedulers is not a viable option, being able to
choose which one was built into the kernel would be easy (only takes a
few ifdefs), i too think competition would be good

-

[ message continues ]

Neither sharing code nor data structures is strictly necessary for a
pluggable scheduler. For instance, backing out per-cpu runqueues in
favor of a single locklessly-accessed queue or similar per-leaf-domain
queues is one potential design alternative (never mind difficulties
with ->cpus_allowed) explicitly considered for the sake of sched_yield()
semantics on SMP, among other concerns. What plugsched originally did
was to provide a set of driver functions and allow each scheduler to
play with its private data declared static in separate C files in what
were later intended to become kernel modules. As far as I know, runtime
switchover code to complement all that has never been written in such a
form. One possibility abandoned early-on was to have multiple schedulers
simultaneously active to manage different portions of the system with
different policies, in no small part due to the difficulty of load
balancing between the partitions associated with the different schedulers.
Some misguided attempts were made to export the lowest-level API possible,
which I rather quickly deemed a mistake, but they still held to such
largely design considerations as I described above.


-- wli
-

[ message continues ]

Given where the code originally came from, I've got bullets to dodge.




Impoliteness doesn't accomplish anything I want to do.




I'm more of a cooperative than competitive person, not to say that
flies well in Linux. There are more productive uses of time than having
everyone NIH'ing everyone else's code. If the result isn't so great,
I'd rather send them code or talk them about what needs to be done.




Decisions with respect to overall kernel design are made from well
above my level. Similarly with coding style, release management, code
directory hierarchy, nomenclature, and more. These things are Linus'
and devolved to those who go along with him on those fronts. If I
made those decisions, you might as well call it "wlix" not "Linux."




The extant versions of it fall well short of Linus' challenge as well
as my original goals for it. A useful exercise may also be enumerating
your expectations and having those who actually work with the code
describe how well those are actually met.


-- wli
-

[ message continues ]

Fair enough.  But being honest about it, without flaming, may be more 

Ok, let's call it cooperative competitiveness.  You know, the kind of 


A runtime configurable framework that allows for dynamically extensible 
schedulers.  PlugSched seems to be a good start.


Thanks!

--
Al



-

[ message continues ]

There was no flamage. It is literally true.




This trips over ideological issues best not discussed on lkml.




You'd be well-served by talking to Peter Williams sometime. He's a
knowledgable individual. I should also mention that Con Kolivas did
significant amounts of work to get the early codebase he inherited
from me working before things were handed off to Peter Williams.




Last I checked there were limits to runtime configurability centering
around only supporting a compiled-in set of scheduling drivers, unless
Peter's taken it the rest of the way without my noticing. It's unclear
what you have in mind in terms of dynamic extensibility. My only guess
would be pluggable scheduling policy/class support for individual
schedulers in addition to plugging the individual schedulers, except
I'm rather certain that Williams' code doesn't do anything with modules.


-- wli
-

[ message continues ]

Correct, it doesn't, yet.  But do you think that PlugSched has the basic 
infrastructure in place to support this, or would it require a complete 
redesign/rewrite.


Thanks!

--
Al

-

[ message continues ]

The piece I got done was just representing schedulers as driver-like
affairs (which, embarrassingly enough, needed lots of bugfixing), and
everyone's just been running with that and boot-time switching ever
since. Runtime switching (to module-loaded schedulers or otherwise)
needs a lot of hotplug-esque work. Scheduler class support, pluggable
or otherwise, needs per-scheduler abstracting things out along the same
lines as what was originally done for the overall schedulers
surrounding enqueueing and dequeueing so the scheduler itself only
plucks tasks out of and stuffs tasks into some sort of abstracted-out
queue or set of queues, though I did try to break things down at a low
enough level where they'd be plausible for more than just the one
driver (never distributed) I used to test the design. I dumped the
entire project long before ever getting to where modules entered the
picture, and have never touched modules otherwise, so I'm not entirely
sure what other issues would come up with those after the smoke clears
from runtime switching.

I don't plan on doing anything here myself, since the boot-time
switching etc. is likely already considered offensive enough.

The next time something comes up that bears a risk of positioning me
against the kernel's political winds, I'll just rm it or not write it
at all instead of leaving code around (or worse yet, passing it around)
to be taken up by others. It just leaves a lot of embarrassed explaining
to do when it resurfaces years later, or otherwise leaves a rather bad
taste in my mouth when NIH'd years later like other things not mentioned
here (VM code kept quiet similarly to plugsched) and everyone approves
so long as it didn't come from me.


-- wli
-

[ message continues ]

The point Linus is makeing is that with pluggable schedulers there isn't 
competition between them, the various developer teams would go off in their own 
direction and any drawbacks to their scheduler could be answered with "that's 
not what we are good at, use a different scheduler", with the very real 
possibility that a person could get this answer from ALL schedulers, leaving 
them with nothing good to use.

David Lang
-

[ message continues ]

Have you noticed that currently that is exactly what happens? If the 
default scheduler doesn't handle your load well you have the option of 
rewriting it and maintaining it, or doing without, or tying to fix your 
case without breaking others, or patching in some other, non-mainline, 
scheduler.

The default scheduler has been around long enough that I don't see it 
being tuned for any A without making some B perform worse. Thus multiple 
schedulers are a possible solution.

They don't need to be available as runtime choices, boot time selection 
would still allow reasonable testing. I can see myself using a compile 
time option and building multiple kernels, but not the average user.

-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-

[ message continues ]