Messages in this thread | | | Date | Thu, 07 Oct 2004 07:49:58 -0700 | From | "Martin J. Bligh" <> | Subject | Re: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement |
| |
> On Thu, 7 Oct 2004, Paul Jackson wrote: > >> > I don't see what non-exclusive cpusets buys us. >> >> One can nest them, overlap them, and duplicate them ;) > > I would also add, if the decision comes to make 'real exclusive' cpusets, > my previous example, as a use for non-exclusive cpusets: > > we are running jobs that need to be 'mostly' isolated on some part of the > system, and run in a specific location. We use cpusets for that. But we > can't afford to dedicate a part of the system for administrative tasks > (daemons, init..). These tasks should not be put inside one of the > 'exclusive' cpusets, even temporary : they do not belong there. They > should just be allowed to steal a few cpu cycles from time to time : non > exclusive cpusets are the way to go.
That makes no sense to me whatsoever, I'm afraid. Why if they were allowed "to steal a few cycles" are they so fervently banned from being in there? You can keep them out of your userspace management part if you want.
So we have the purely exclusive stuff, which needs kernel support in the form of sched_domains alterations. The rest of cpusets is just poking and prodding at cpus_allowed, the membind API, and the irq binding stuff. All of which you could do from userspace, without any further kernel support, right? Or am I missing something?
M.
- 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/
| |