linux-kernel - Re: Pluggable Schedulers (was: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 10 Mar 2007 11:31:00 -0800
From:	William Lee Irwin III <wli@...omorphy.com>
To:	Al Boldi <a1426z@...ab.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Pluggable Schedulers (was: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler)

William Lee Irwin III wrote:
>> 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.

On Sat, Mar 10, 2007 at 07:47:11PM +0300, Al Boldi wrote:
> 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.

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/