![]() | ||||||||||
Messages in this thread |
On 20020107 Andrea Arcangeli wrote: > >yes please (feel free to CC me on the answers), I'd really like to >reduce the scheduler O(N) overhead to the number of the running tasks, >rather than doing the recalculate all over the processes in the machine. >O(1) scheduler would be even better of course, but the below would >ensure not to hurt the 1 task running case, and it's way simpler to >check for correctness (so it's easier to include it as a start). > It looks like you all are going to turn the scheduler upside-down. Hmm, as a non-kernel-hacker observer from the world outside, could I make a suggestion ? Is it easy to split the thing in steps: - Move from single-queue to per-cpu-queue, with just the same algorithm that is running now for per-queue scheduling. - Get that running for 2.18.18 and 2.5.2 - Then start to play with the per-queue scheduling algorithm: * better O(n) * O(1) * O(1) with different queues for RT and non RT etc... Is it easy enough or are both steps so related that can not be split ? Thanks. (a linux user that tries experimental kernels and is seeing them grow like mushrooms in latest weeks...) -- J.A. Magallon # Let the source be with you... mailto:jamagallon@able.es Mandrake Linux release 8.2 (Cooker) for i586 Linux werewolf 2.4.18-pre1-beo #1 SMP Fri Jan 4 02:25:59 CET 2002 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | |||||||||
| Last update: 2005-03-22 12:15 [from the cache] ©2003-2008 | ||||||||||