cdjones-freebsd-hackers at novusordo.net
Sun Jun 11 17:36:48 UTC 2006
On 11-Jun-06, at 6:50 AM, Pieter de Goeje wrote:
> For my CS study I picked up "Operating System Concepts" by
> Galvin and Gagne. It has a fairly detailed description of the inner
> of a scheduler and the various algorithms involved, but no actual
Yep, we used the Dinosaur Book and I've still got it. I may even
have Tanenbaum's OS book kicking around somewhere.
>> - what're your thoughts on making the existing scheduler jail-
>> aware as opposed to writing a sort of 'meta-scheduler' that would
>> schedule between jails, and then delegate to a scheduler per jail
>> (which could be very similar, if not identical, to the existing
>> scheduler)? I've got some very preliminary thoughts on this, but I'd
>> like to hear what you've got to say, as I'm aware that this is
>> rather ... complex.
> I suppose by limiting the jail CPU usage you mean that jails
> contending over
> CPU each get their assigned share. But when the system is idle one
> jail can
> get all the CPU it wants.
Exactly. Think of it as being like nice-on-steroids, but for a whole
jail instead of a process.
> Suppose you could detect wether a certain jail used too much CPU,
> wouldn't it
> be possible to lower the priorities of all the processes running
> inside that
> jail? And when the jail is "behind" on it's CPU quota, raise their
> back to normal.
> I guess you could implement such a thing by a hook in the scheduler
> examines the current CPU usage of each jail, say each second, and
> appropriate action accordingly.
That's one way to do it using one big scheduler; on the other hand,
the hierarchical scheduler approach could be as trivial as round-
robin timeslicing on the "metascheduler" between the individual
jails' schedulers (obviously, you'd really want at least to be able
to do proportional timeslicing and probably to set the schedulers up
to hand their timeslice back if they'd otherwise run the idle process).
Joerg: thanks for the pointer to Luigi's scheduler; I'll check it out.
More information about the freebsd-hackers