Messages in this thread |  | | | Date | Wed, 6 Oct 2004 11:43:40 +0200 (CEST) | | From | Simon Derr <> | | Subject | Re: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement |
| |
On Tue, 5 Oct 2004, Paul Jackson wrote:
> Matthew wrote: > > > > By adding locking and reference counting, and simplifying the way in which > > sched_domains are created, linked, unlinked and eventually destroyed we > > can use sched_domains as the implementation of cpusets. > > I'd be inclined to turn this sideways from what you say. > > Rather, add another couple of properties to cpusets: > > 1) An isolated flag, that guarantees whatever isolation properties > we agree that schedulers, allocators and resource allocators > require between domains, and > > 2) For those cpusets which are so isolated, the option to add > links of some form, between that cpuset, and distinct scheduler, > allocator and/or resource domains. >
Just to make sure we speak the same language:
That would lead to three kinds of cpusets:
1-'isolated' cpusets, with maybe a distinct scheduler, allocator and/or resource domains.
2-'exclusive' cpusets (maybe with a better name?), that just don't overlap with other cpusets who have the same parent.
3-'non-exclusive, non isolated' cpusets, with no restriction of any kind.
I suppose it would still be possible to create cpusets of type 2 or 3 inside a type-1 cpuset. They would be managed by the scheduler of the parent 'isolated' cpuset.
I was thinking that the top cpuset is a particular case of type-1, but actually no.
'isolated' cpusets should probably be at the same level as the top cpuset (who should lose this name, then).
How should 'isolated' cpusets be created ? Should the top_cpuset be shrunk to free some CPUs so we have room to create a new 'isolated' cpuset ?
Or should 'isolated' cpusets stay inside the top cpuset, that whould have to schedule its processes outside the 'isolated' cpusets ? Should it then be forbidden to cover the whole system with 'isolated' cpusets ?
That's a lot of question marks... - 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/
|  |