Stefan Smietanowski <[email protected]> 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. But IMHO, this should
>> definitely not be put in cpuinfo. I consider that cpuinfo is for the human.
>
> When one defines it one way you can be sure there'll come some company
> and figure something out that doesn't fit into that representation.
>
> Like - Stick a board into the CPU slot of some motherboard. That board
> has two DualCore, SMT chips.
Obviously it must be a tree of CPU groups. CPUs in one NUMA node go into
one group, multi-core CPUs have all cores in one group and HT is a group,
too. This will scale from UP (degenerated tree with just one CPU) to
clusters with multicore HT-capable CPUs on PCI boards.
e.g. if you choose to represent it as a string:
Object = <Offline-Indicator>? (<CPU>|<Group>) <Details>?
Offline-Indicator = "-"
CPU = qr/[a-z0-9_]+/ # or more restrictive
Group = "[" (<Object>)("," <Object>)* "]"
Details = "{" (<vardef)("," <Vardef>)* "}"
Vardef = <Key> "=" <Value> # or "=>" if you think perl
Key = qr/[a-z0-9_]+/
Value = qr/"([^"\000]|"")*"/
The described board in a UP system might look like:
[cpu0{speed="4.77MHz", RAM="80KB"},
[[[boardcpu0_0, boardcpu0_0_ht]{group="ht"},
[boardcpu0_1, boardcpu0_1_ht]{group="ht"}],
[[boardcpu1_0, boardcpu1_0_ht]{group="ht"},
[boardcpu1_1, boardcpu1_1_ht]{group="ht"}]{group="numa",RAM="4GB"}]
To count them, do:
#/usr/bin/perl
s/"[^"]*"//g;
s/\{[^}]*\}//g;
$numcpus=s/,/,/g + 1;
--
Top 100 things you don't want the sysadmin to say:
43. The backup procedure works fine, but the restore is tricky!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
