> Possibly, if it was some kind of multi-level scheduler - i.e. a > top-level scheduler picks which container to run, and then a > configurable per-container scheduler picks a task from that container.
What do you think about Plugsched? Peter Williams introduced a simple scheduler interface for scheduler testing purposes. It should be possible to integrate into your CPU Controller. The CPU Controller seems to be quite suited for that purpose, as far as I can appraise after reading some of your documentation. Unfortunately, I didn't know about CKRM some months ago, when we decided to use cpusets. As I wrote, Dynsched is a student project at sunset and it's future is quite ambiguous. Maybe we'll find some time to take a look at. > But (having glanced at the code even less than you) it sounded like it > was intended to be a single level scheduler, configured on a per-cpu > basis. In that case tying it to (exclusive) cpusets sounds like it > might be more reasonable. You're right. We tie up the scheduler to cpus with some per_cpu functionality, and chose cpusets for management, cause we didn't want add another interface (e.g sysfs files for each cpu). Cpusets is quite adequate for our purpose, but there are lots of issues we're currently dealing with. Think about (not exclusive) subsets with different schedulers... Felix - 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/
