> On 7/9/07, Alexander Kolbasov <[EMAIL PROTECTED]> wrote: > > > > Hello, > > > > I would like to propose a new "CPUfs" project aimed at providing extended > > observability for the CPUs in the system and their sharing relationships. > > The > > main objective is to provide stable infrastructure for representing CPU > > properties for user-land applications. > > > > Currently some CPU-related information can be obtained using prtconf(1M) > > and > > psrinfo(1M) which just a wrapper around the kstat (1M) framework. The > > kstat > > framework is usable for representing simple "flat" CPU properties, but > > using it > > becomes more and more of a stretch in the CMT world. > > > > The purpose of the CPUfs project is to explore using the file system > > abstraction > > to represent CPU properties. File system abstraction supports hierarchy > > and > > convenient name space. > > > > I suggest hosting the project under either Observability or Performance > > community. > > > As a sysadmin, I would find this functionality very useful. Currently I have > to resort to parsing a combination of psrconf and psrinfo, and the format of > the output is inconsistent, so I have to keep updating my code every time > that a new CPU type is added to Solaris. > > One concern is to make sure that this is designed as a "stable interface" > that can scale to handle most CPU configurations looking down the road.
Yes, this is a very important point. > We will probably need to handle the virtualization extensions properly as > well. (As related to Xen, Zones and VMWare). I'm thinking that we need to > focus on creating a standard format "feature matrix". This would allow new > features to be added down the road, while allowing code to check for the > existence of features, without knowing or caring what particular model of > chip. (I know I am probably stating the obvious). > > One question to consider is do we want to also support something similar to > Linux's "/proc/cpuinfo"? > > e.g.: > > debian-macbook:/usr/src# cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 14 > model name : Genuine Intel(R) CPU T2500 @ 2.00GHz > stepping : 8 > cpu MHz : 1000.000 > cache size : 2048 KB > physical id : 0 > siblings : 2 > core id : 0 > cpu cores : 2 > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 10 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge > mca cmov pat clflush dts acpi mmx fxsr sse > sse2 ss ht tm pbe nx constant_tsc pni monitor vmx est tm2 > xtpr > bogomips : 3999.30 Currently we provide something similar using kstats. We can certainly do this, if there is a need, but I think that is more useful to provide such information in a more structural way. For example, we may have a file for each property which contains the property value. - akolb _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
