Re: [rfc][patch] 1/2 Additional cpuset features

[Anton Blanchard <anton@samba.org>]

 
Hi,

> > But the jist of the matter is simple.  Just as we (SGI) did with
> > cpumemsets and perfmon on 2.4 kernels, so should we do with cpusets and
> > perfmon on 2.6 kernels.  And that is to perform this translation in
> > perfmon code.  Is it only SGI's dplace that requires the cpuset-relative
> > numbering?
> 
> pfmon, sched_setaffinity, dplace. And this is only what I saw today.
> Might develop into a longer list. The 2.4 solutions were rather
> complicated.

Are pfmon and dplace SGI specific? sched_affinity users already have to
deal with potentially discontiguous cpu maps. Ive been teaching IBM
applications about this fact as I find problems.

> > The kernel-user boundary should stick to a single, system-wide, numbering
> > of CPUs.
> 
> That leads to lots of complicated scripts doing logical -> physical
> translation with the danger of access or attempting accesses to not
> allowed CPUs. It may be easier to contain tasks into a range of cpus if
> the CPUs in use are easily enumerable.

I would think you could write this in your userspace library.

> The patch would allow the use of the existing tools as if the machine
> only had N cpus (as you said a soft partitioning of the machine). If
> scripts are to be used with the current approach then they need to know
> about all the CPUs in the system and perform the mapping. Its going to be
> a nightmare to develop scripts that partition off a 512 cpu cluster
> appropriately and that track the physical cpu numbers instead of the cpu
> number within the cpuset.

What happens when an application (or user) looks in /proc/cpuinfo?
And how does /sys/.../cpus match? Also what happens when you hotplug out 
a cpu and your memory map becomes discontiguous? 

Anton