Messages in this thread | | | Subject | Re: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement | From | Matthew Dobson <> | Date | Tue, 05 Oct 2004 15:33:46 -0700 |
| |
On Tue, 2004-10-05 at 02:26, Simon Derr wrote: > I'd like to present you at this point what was the original decision for > having exclusive (called strict, at this point in history) and > non-exclusive cpusets. > > The idea was to have a system, and run all jobs on it through a batch > scheduler. Some jobs cared about performance, some didn't. > > The ones who cared about performance got an 'exclusive' cpuset, the ones > who didn't got a 'non exclusive' cpuset.
It sounds to me (and please correct me if I'm wrong) like 'non exclusive' cpusets are more like a convenient way to group tasks than any sort of performance or scheduling imperative. It would seem what we'd really want here is a task grouping functionality, more than a 'cpuset'. A cpuset seems a bit heavy handed if all we want to do group tasks for ease of administration.
> There are still processes running outside the job cpusets (i.e in the root > cpuset), sshd, the batch scheduler. These tasks use a low amount of CPU, > so it is okay if they happen to run inside even 'exclusive' cpusets. For > us, 'exclusive' only means that no other CPU-hungry job is going to share > our CPU.
If that's all 'exclusive' means then 'exclusive' is a poor choice of terminology. 'Exclusive' sounds like it would exclude all tasks it is possible to exclude from running there (ie: with the exception of certain necessary kernel threads).
-Matt
- 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/
| |