Sherry Moore <[EMAIL PROTECTED]> 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
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org

Reply via email to