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