On 11-Jun-06, at 6:50 AM, Pieter de Goeje wrote:
For my CS study I picked up "Operating System Concepts" by
Silberschatz,
Galvin and Gagne. It has a fairly detailed description of the inner
workings
of a scheduler and the various algorithms involved, but no actual
implementation.
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
priorities
back to normal.
I guess you could implement such a thing by a hook in the scheduler
which
examines the current CPU usage of each jail, say each second, and
takes
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.
Cheers,
Chris
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
