Sherry Moore <sherry.moore at sun.com> wrote:
>> $ cat /system/cpufs/cpus/0/vendor_string
>> $ cat /system/cpufs/cpus/0/l2_cache_size
>>
>> be sufficient? If the information is available through the CPUfs
interface it
>> is easy to build wrapper library in any language for accessing it
>> programmatically.
Sherry> I like the objective of obtaining all the cpuid information in a
Sherry> human-interpretable and consistent way from both the kernel and
Sherry> userland. However, I am not convinced that the best solution is a
file
Sherry> system like abstraction.
There is nothing wrong with having a nice API for obtaining various
CPU-related information, which can replace kstats and accessing
/dev/cpu/self. We also need to provide high-level tools to access such
information. Unless you imply that the file--system representation is not
adequate in the first place and one may be actually based on another.
Sherry> The bottom line is that, most, if not all, CPU related information
is
Sherry> already available in cpuid_info. Currently in the kernel, the
Sherry> information is available via various cpuid_get_* functions. I find
Sherry> that interface quite acceptable (even though it could use some
Sherry> extension). What we lack is the ability to extract the same
Sherry> information in userland. I think a much lighter weight solution is
to
Sherry> provide a library to extract such information from cpuid_info. If
we
Sherry> don't want to extend cpu_info for kstat, a new command "cpuinfo"
can be
Sherry> introduced to present the properties.
There is nothing wrong in providing an interface to extract cpuid
extraction and it can be done in some pretty simple way (e.g. providing
cpuid field(s) for the cpu_info kstat). But sun4v platforms use MD
(machine description) API instead, and we also need to provide
visibility into Processor Groups which can't be extracted from just
cpuid. Should we continue overloading kstat framework with more cludges
or it would be better to have something more suitable for the job of
representing hierarchical CPU properties? Should we have libcpuid and libpg?
Sherry> The file system abstraction adds quite a bit of complexity. I don't
Sherry> think it makes representing/interpreting the new complicate NUMA and
Sherry> CMT features any easier. For example, how do we show that L2 is
shared
Sherry> between core 0 and core 1, and L3 is shared between core 0-3,
without
Sherry> adding many more properties, and without visiting 4
Sherry> directories?
Can we do this by constructing the tree so that sharing relationships
become obvious just by looking at the full path in the directory? For
example, we can have something like
.../L2_cache/0/ipipe/1/cpu/3
and
.../L2_cache/0/ipipe/2/cpu/4
This shows that instruction pipelines 1 and 2 share the same L2 and
CPus 3 and 4 share the same core and same L2 cache.
How easy would be expressing such relationships on a sun4v platform and
what should be the API for asking this sort of questions?
- akolb
