Re: /proc/cpuinfo format - arch dependent!

[Dave Jones <davej@redhat.com>]

On Sat, May 07, 2005 at 09:58:29AM +0200, Willy Tarreau wrote:

 > I personally think that what would be useful is not "the number of CPUs"
 > (which does not make any sense), but an enumeration of :
 > 
 >     - the physical nodes (for NUMA)
 >     - the physical CPUs
 >     - each CPU's cores (for multi-core)
 >     - each core's siblings (for HT/SMT)
 > 
 > each of which would report their respective id for {set,get}_affinity().
 > This way, the application would be able to choose how it needs to spread
 > over available CPUs depending on its workload.

Typically, the application shouldn't care. The scheduler should be
deciding where processes would be best run.

 > > Probably these things can be worked out via the get/set_affinity() syscalls
 > > and/or via the cpuset sysfs interfaces, but it isn't as simple as you're
 > > assuming.
 > 
 > At least it would be simpler with some layout info like above.

There's nothing stopping a process from parsing /dev/cpu/x/cpuid
to find out anything it wants about the layout of cores/siblings,
but I'll bet you'd be hard pressed to find a single application
that would benefit from knowing about the layout.
Processes know nothing about what the kernel has scheduled on
other threads/cores, and they shouldn't. Trying to do the same
cpu arbitration in userspace is madness.

What /could/ be useful would be a way to tell sched_setaffinity
and co "I have two threads, I'd like them both to run on different cores,
avoiding HT pairs, and never be migrated off them" without having to care
about the layout of the cpus in each application.

		Dave