Date: Sun, 11 Jun 2006 18:38:52 -0700 From: "Kip Macy" <kip.macy@gmail.com> To: "Peter Jeremy" <peterjeremy@optushome.com.au> Cc: Pieter de Goeje <pieter@degoeje.nl>, Chris Jones <cdjones-freebsd-hackers@novusordo.net>, freebsd-hackers@freebsd.org Subject: Re: Jail-Aware Scheduling Message-ID: <b1fa29170606111838t55f40230kf5e40cbd1df7aaa1@mail.gmail.com> In-Reply-To: <20060612001524.GD739@turion.vk2pj.dyndns.org> References: <1A2863A3-21D6-4F38-AB98-BAB605507095@novusordo.net> <200606111450.31041.pieter@degoeje.nl> <20060612001524.GD739@turion.vk2pj.dyndns.org>
index | next in thread | previous in thread | raw e-mail
I personally prefer the notion of layering the normal scheduler on top
of a simple fair-share scheduler. This would not add any overhead for
the non-jailed case. Complicating the process scheduler poses
maintenance, scalability, and general performance problems.
-Kip
On 6/11/06, Peter Jeremy <peterjeremy@optushome.com.au> wrote:
> On Sun, 2006-Jun-11 14:50:30 +0200, Pieter de Goeje wrote:
> >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.
>
> IBM MVS had an interesting alternative approach, which I believe was
> part of the scheduler: You could place an upper limit on the CPU
> allocated to a process. From a user perspective, an application would
> respond in (say) 2 seconds whether the system was completely idle or
> at normal load. This stopped users complaining that the system was
> slow as the system got loaded. In the case of jailed systems, it
> could also prevent (or minimize) traffic analysis of the system by a
> jailed process.
>
> --
> Peter Jeremy
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
>
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b1fa29170606111838t55f40230kf5e40cbd1df7aaa1>