On Fri, Mar 09, 2007 at 05:18:31PM -0500, Ryan Hope wrote: > from what I understood, there is a performance loss in plugsched > schedulers because they have to share code.... > even if pluggable schedulers is not a viable option, being able to > choose which one was built into the kernel would be easy (only takes a > few ifdefs), i too think competition would be good
Neither sharing code nor data structures is strictly necessary for a pluggable scheduler. For instance, backing out per-cpu runqueues in favor of a single locklessly-accessed queue or similar per-leaf-domain queues is one potential design alternative (never mind difficulties with ->cpus_allowed) explicitly considered for the sake of sched_yield() semantics on SMP, among other concerns. What plugsched originally did was to provide a set of driver functions and allow each scheduler to play with its private data declared static in separate C files in what were later intended to become kernel modules. As far as I know, runtime switchover code to complement all that has never been written in such a form. One possibility abandoned early-on was to have multiple schedulers simultaneously active to manage different portions of the system with different policies, in no small part due to the difficulty of load balancing between the partitions associated with the different schedulers. Some misguided attempts were made to export the lowest-level API possible, which I rather quickly deemed a mistake, but they still held to such largely design considerations as I described above. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
