9b5f73976d
Changes paffinity interface to use a cpu mask for available/preferred cpus rather than the current coarse grained paffinity that lets the OS choose which processor. Macros for setting and clearing masks are provided. Solaris and windows changes have not been made. Solaris subdirectory has some suggested changes - however the relevant man pages for the Solaris 10 APIs have some ambiguity regarding order in which one create and sets a processor set. As we did not have access to a solaris 10 machine we could not test to see the correct way to do the work under solaris. This commit was SVN r14887.
64 строки
2.5 KiB
Plaintext
64 строки
2.5 KiB
Plaintext
(from helpful AMD engineers...)
|
|
|
|
Jeff,
|
|
|
|
Bill asked me to expand on what I previously wrote by documenting the
|
|
/sys interface. Without further ado:
|
|
|
|
All the information you need for determining the topology of a given
|
|
core is located in the /sys/devices/system/cpu/cpuX/topology/
|
|
directory, where X is a core number from 0 to N - 1, given N total
|
|
cores present on the system. On an AMD64 system, this directory will
|
|
contain the following entries, readable in ASCII form:
|
|
|
|
physical_package_id - which socket am I in?
|
|
core_id - in my socket, which core am
|
|
I? (0 or 1
|
|
for dual-core CPUs)
|
|
core_siblings - who are my sibling cores in this
|
|
socket? (see below)
|
|
thread_siblings - who are my sibling threads
|
|
in this
|
|
socket? (not really useful for AMD64)
|
|
|
|
The sibling fields are given as bit masks of core IDs, represented as
|
|
hexdecimal numbers delimited by commas into groups of eight for easier
|
|
readability. So for example, given a kernel that supports a maximum
|
|
of 128 cores:
|
|
|
|
cparrott@compute-2:~> cat
|
|
/sys/devices/system/cpu/cpu0/topology/core_siblings
|
|
00000000,00000000,00000000,00000003
|
|
|
|
would tell us that cores 0 and 1 are the sibling cores of core 0.
|
|
Each core is included in its own sibling core mask, so you would still
|
|
get a meaningful result if you happened to be running on a single-core
|
|
system.
|
|
|
|
Given that these are NUMA systems, you may assume that each socket may
|
|
or may not have a region of memory associated with it. Most systems
|
|
do, but I have seen a few that had sockets without associated memory.
|
|
My dual-Opteron Linux workstation system at my desk is a prime example
|
|
of this -- all of its memory appears to the kernel as being directly
|
|
connected to socket 0.
|
|
|
|
Unfortunately, I am not aware of an easy mechanism for determining the
|
|
memory associated with a given socket, although this information does
|
|
show up in the kernel messages buffer during boot. (i.e. run dmesg)
|
|
Perhaps Ray might know.
|
|
|
|
------
|
|
|
|
Followup to this:
|
|
|
|
The /sys/devices/system/node/ directory tree contains the memory node
|
|
topology. Of particular interest here is numastat entry: this will
|
|
give stats on which of this node's pages are physically located here
|
|
versus foreign nodes, for example.
|
|
|
|
Unfortunately, memory mappings for specific address ranges to nodes
|
|
are not available. I suspect that this is probably due to the fact
|
|
that Linux uses virtual addressing everywhere in userland, so any
|
|
physical address ranges corresponding to a particular memory node are
|
|
meaningless in userland.
|