* Date: Fri, 3 Aug 2007 15:19:00 +0200
* Received-SPF: softfail (mx3: transitioning domain of elte.hu does not
designate 157.181.1.14 as permitted sender) client-ip=157.181.1.14; [EMAIL
PROTECTED]; helo=elvis.elte.hu;
> If you boot into a distro kernel on
> a typical PC, about half of the kerne
On 08/07/2007 01:35 AM, Rene Herman wrote:
On 08/06/2007 11:48 PM, Mitchell Erblich wrote:
Of the uni-processor systems currently that can run Linux, I would not
doubt if 99.% percent are uni-cores.
s/can// and I would. s/uni-processor// additionally and I'd assure you
it's untrue. s/un
On 08/06/2007 11:48 PM, Mitchell Erblich wrote:
Of the uni-processor systems currently that can run Linux, I would not
doubt if 99.% percent are uni-cores.
s/can// and I would. s/uni-processor// additionally and I'd assure you it's
untrue. s/uni-cores/non-smt uni-cores/ and I'd do the sam
Rene,
Of the uni-processor systems currently that can run Linux, I would not
doubt if 99.% percent are uni-cores. It will be probably
3-5 years minimum before the multi-core processors will have any
decent percentage of systems.
And I am not suggesting not supporting them
On 08/06/2007 10:20 PM, Mitchell Erblich wrote:
Thus, a hybrid schedular approach could be taken
that would default to a single uni-processor schedular
What a brilliant idea in a world where buying a non multi core CPU is
getting to be only somewhat easier than a non SMT one...
Rene
Ingo Molnar and group,
If we just concentrate on CPU schedulars...
IMO, POSIX requirements almost guarantee
the support for modularization. The different
task scheds allow a set of task class specific
funcs to be generated. The question is whether
those modular sched
* Rene Herman <[EMAIL PROTECTED]> wrote:
> On 08/03/2007 03:19 PM, Ingo Molnar wrote:
>
> > One of the authors of the IO scheduler code said it on lkml recently
> > that while modularization of IO scheduler had advantages too, in
> > retrospect he wishes they would not have made IO schedulers
On 08/03/2007 03:19 PM, Ingo Molnar wrote:
One of the authors of the IO scheduler code said it on lkml recently that
while modularization of IO scheduler had advantages too, in retrospect he
wishes they would not have made IO schedulers modular and now that
decision cannot be undone.
Just as a
* debian developer <[EMAIL PROTECTED]> wrote:
> > 1 - Can someone please explain why the kernel can be modular in
> > every other aspect, including offering a choice of IO schedulers,
> > but not kernel schedulers?
>
> Good question. has been answered in other threads. Linus does'nt like
> ha
* T. J. Brumfield <[EMAIL PROTECTED]> wrote:
> CFS is apparently better in its simplicity, however others are
> reporting that SD still provides benefits for 3D gaming. [...]
even for 3D gaming the opposite of what you say seems to be the case:
http://people.redhat.com/mingo/misc/cfs-sd-ut20
* T. J. Brumfield <[EMAIL PROTECTED]> wrote:
> On 8/3/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > snip...
>
> Except that a working prototype of plugsched exists and functions
> exactly as advertised. [...]
a prototype for dynamic syscalls exists too. A prototype for pluggable
network IPv4
On 8/3/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> snip...
Except that a working prototype of plugsched exists and functions
exactly as advertised. I understand that modules can be loaded and
unloaded, where as other aspects of the core kernel can't just
load/unload as the kernel is running, but
* T. J. Brumfield <[EMAIL PROTECTED]> wrote:
> 1 - Can someone please explain why the kernel can be modular in every
> other aspect, including offering a choice of IO schedulers, but not
> kernel schedulers?
that's a fundamental misconception. If you boot into a distro kernel on
a typical PC,
13 matches
Mail list logo
