[lkml]   [2004]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [rfc][patch] 1/2 Additional cpuset features


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

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:06    [W:0.049 / U:1.416 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site