Re: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement

[Erich Focht]

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...

Regards,
Erich

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/