Messages in this thread | | | From | Erich Focht <> | Subject | Re: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement | Date | Fri, 6 Aug 2004 17:55:40 +0200 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |