[lkml]   [2004]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement
On Friday 06 August 2004 17:35, Martin J. Bligh wrote:
> > I'd vote for cpusets going in soon. CKRM could be extended by
> > a cpusets controller which should be pretty trivial when using the
> > infrastructure of this patch. It simply needs to create classes
> > (cpusets) and attach processes to them. The enforcement of resources
> > happens automatically. When CKRM is mature to enter the kernel, one
> > could drop /dev/cpusets in favor of the CKRM way of doing it.
> But I think that's dangerous. It's very hard to get rid of existing user
> interfaces ... I'd much rather we sorted out what we're doing BEFORE
> putting either in the kernel.

So the user interfaces should be adapted before? I think this is
simple and then the elimination of /dev/cpusets in favor of /rcfs is
just deletion of code plus a simbolic link. The classes and cpusets
are both directories. The files in cpusets are:
- cpus: list of CPUs in that cpuset
- mems: list of Memory Nodes in that cpuset
- cpu_exclusive flag: is cpu placement exclusive?
- mem_exclusive flag: is memory placement exclusive?
- tasks: list of tasks (by pid) attached to that cpuset
The files in a CKRM class directory:
- stats : statistics (not needed for cpusets)
- shares : could contain cpus, mems, cpu_exclusive, mem_exclusive
- members : same as reading /dev/cpusets/.../tasks
- target : same as writing /dev/cpusets/.../tasks

Changing the "shares" would mean something like
echo "cpus +6-10" > .../shares
Just an idea...


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:05    [from the cache]
©2003-2011 Jasper Spaans