|| ||Nick Piggin <email@example.com>|
|| ||linux-kernel <firstname.lastname@example.org>|
|| ||[RFC] generalise scheduling classes|
|| ||Sun, 23 Nov 2003 22:57:54 +1100|
|| ||"Martin J. Bligh" <email@example.com>,
Andi Kleen <firstname.lastname@example.org>, Ingo Molnar <email@example.com>,
Andi Kleen <firstname.lastname@example.org>, Con Kolivas <email@example.com>,
Andrew Morton <firstname.lastname@example.org>, email@example.com,
firstname.lastname@example.org, John Hawkes <email@example.com>, firstname.lastname@example.org|
We still don't have an HT aware scheduler, which is unfortunate because
weird stuff like that looks like it will only become more common in future.
I made a patch on top of my recent NUMA/SMP scheduling stuff to implement
generalised scheduling classes. With this modification we can allow
architectures to control scheduling policy in a much finer way.
Hyperthreading should be no problem, hierarchical (NUMA) nodes should
be doable as well.
I'm not exactly sure how architecuture specific code is supposed to be
handled, I'll have to have a look at some examples. Basically architectures
build up your own scheduling "classes".
I have supplied a default function to build up the classes if none is
supplied. It builds them so functionality should be similar to the
previous standard local / remote behaviour.
Haven't done much testing yet, just asking for comments. Will these
classes be sufficient for everyone?
Class is struct sched_class in include/linux/sched.h
Default classes are built by arch_init_sched_classes in kernel/sched.c
The patch in question is this one
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/