On 7/9/07, Alexander Kolbasov <[EMAIL PROTECTED]> wrote:
> 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.
Many Linux apps, expect to be able to parse the output of /proc/cpuinfo. My thought was that it would probably make it easier to port Linux apps, if we supported the CPU/system metadata in the same format. (This is just my opinion, not a requirement). This is not to say that we can't support our own method in addition. Because I have been working on designing a Systems Inventory Data object model, I have been thinking about this for some time. One of the first things we may want to do is develop the "CPU metadata model". Do you have something in mind yet? --brian
_______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
