On Sat, 5 Jan 2002, Davide Libenzi wrote: > > No Ingo the fact that you coded the patch this time does not really change > the workloads, once you've a per-cpu run queue and lock. The thing that > makes big servers to suffer in the common queue plus the cache coherency > traffic due the common lock. What do the per-CPU queue patches look like? I agree with Davide that it seems much more sensible from a scalability standpoint to allow O(n) (or whatever) but with local queues. That should also very naturally give CPU affinity ;) The problem with local queues is how to sanely break the CPU affinity when it needs breaking. Which is not necessarily all that often, but clearly does need to happen. It would be nice to have the notion of a cluster scheduler with a clear "transfer to another CPU" operation, and actively trying to minimize the number of transfers. What are those algorithms like? This are must have tons of scientific papers. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo _at_ vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Follow-Ups:
- Re: [announce] [patch] ultra-scalable O(1) SMP and UP schedulerIngo Molnar <mingo _at_ elte.hu>
- Re: [announce] [patch] ultra-scalable O(1) SMP and UP schedulerDavide Libenzi <davidel _at_ xmailserver.org>
- Prev by Date: Re: oops in devfs
- Next by Date: Re: [announce] [patch] ultra-scalable O(1) SMP and UP scheduler
- Previous by thread: Re: [announce] [patch] ultra-scalable O(1) SMP and UP scheduler
- Next by thread: Re: [announce] [patch] ultra-scalable O(1) SMP and UP scheduler
- Indexes:[Main][Thread]