On Thu, 2004-10-07 at 13:12, Hubertus Franke wrote: > The way this is heading is quite promising. > - sched_domains seems the right answer wrt to partitioning the machine. > Given some boot option or dynamic means one can shift cpus from > on domain to the next domain. > - If I understood correctly, there would be only one level of such > hard partitioning, speak exclusive cpu-set or sched_domain. > - In each such domain/set we allow shared *use*.
I don't think that there needs to be a requirement that we have only one level of hard partitioning. The rest of your points are valid though, Hubertus. It'd be really nice if we could all get together with a wall of whiteboards, some markers, and a few pots of coffee. I think we'd all get this pretty much hashed out in an hour or two. This isn't directed at you, Hubertus, but at the many communication breakdowns in this thread. > First, one needs to understand that sched_domains are nothing else > but a set of cpus that are considered during load balancing times. > By constricting the top_domain to the respective exclusive set one > essentially has accomplished the desired feature of partitioning > the machines into "isolated" sections (here from cpu perspective). > So it is quite possible that an entire domain is empty based, while > another exclusive domain would be totally overloaded. I think that is very well stated, Hubertus. By having a more or less passive data structure that is only checked at load balance time, we can ensure (in a very light-weight way) that no task ever moves *out* of it's area nor moves *into* someone else's area. -Matt ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
