>From [EMAIL PROTECTED] Mon Jul 9 13: 59:12 2007
Return-Path: <[EMAIL PROTECTED]>
Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM
[129.146.11.26])
by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id
l69KxC0Z281295
(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
for <[EMAIL PROTECTED]>; Mon, 9 Jul 2007 13:59:12 -0700 (PDT)
Received: from geralyn.sfbay.sun.com (geralyn.SFBay.Sun.COM [129.146.226.228])
by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with
ESMTP id l69KxCaE021010
for <[EMAIL PROTECTED]>; Mon, 9 Jul 2007 13:59:12 -0700 (PDT)
Received: from geralyn.sfbay.sun.com (localhost [127.0.0.1])
by geralyn.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id
l69KxCad008541;
Mon, 9 Jul 2007 13:59:12 -0700 (PDT)
Received: (from [EMAIL PROTECTED])
by geralyn.sfbay.sun.com (8.14.1+Sun/8.14.1/Submit) id l69KxCpJ008540;
Mon, 9 Jul 2007 13:59:12 -0700 (PDT)
X-Authentication-Warning: geralyn.sfbay.sun.com: sherrym set sender to [EMAIL
PROTECTED] using -f
Date: Mon, 9 Jul 2007 13:59:12 -0700
From: Sherry Moore <[EMAIL PROTECTED]>
To: Brian Gupta <[EMAIL PROTECTED]>
Cc: Alexander Kolbasov <[EMAIL PROTECTED]>,
[EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: Re: [perf-discuss] [observability-discuss] Project proposal: CPUfs
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[EMAIL PROTECTED]>
User-Agent: Mutt/1.4.1i
Resent-To: perf-discuss@opensolaris.org
Resent-Date: Mon, 09 Jul 2007 14:47:39 -0700
Resent-From: Alexander Kolbasov <[EMAIL PROTECTED]>
I share Brian's view on the possibility of implementing something
similar to Linux's /proc/cpuinfo. During my development days on Linux,
I grew quite fond of the /proc/cpuinfo interface, and found it
extremely extensible to include additional information as they become
available on new CPUs.
Another idea I would like to toss around here is the possibility of
libcpuinfo. Currently the only way to get cpuid information in user
applications is via /dev/cpu/self/cpuid. The interface, while
versatle, is not particularly easy to use ("man cpuid" for usage
details). It would be nice to provide interfaces to user applications
to get various fields from cpuid_info. Something like
cpuid_get(VENDOR_STR, &vendor_str);
cpuid_get(L2_CACHE_SIZE, &l2_cache_size);
etc.
Sherry
On Mon, Jul 09, 2007 at 04:12:11PM -0400, Brian Gupta 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.
>
> 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
>
> processor : 1
> 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 : 1
> 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 : 3994.61
>
>
> Thanks,
> --brian
> _______________________________________________
> perf-discuss mailing list
> perf-discuss@opensolaris.org
--
Sherry Moore, Solaris Kernel Development http://blogs.sun.com/sherrym
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
