> Hey Guys,
>
> [dragging up old email]
>
> On Wed, Jul 11, 2007 at 12:29 AM, Brendan Gregg - Sun Microsystems
> wrote:
> > On Mon, Jul 09, 2007 at 11:14:18PM -0700, Alexander Kolbasov wrote:
> >> Hi Brendan,
> >>
> >> can I summarize your point as a proposal to extend kstat framework
> >> inste
Hey Guys,
[dragging up old email]
On Wed, Jul 11, 2007 at 12:29 AM, Brendan Gregg - Sun Microsystems
wrote:
> On Mon, Jul 09, 2007 at 11:14:18PM -0700, Alexander Kolbasov wrote:
>> Hi Brendan,
>>
>> can I summarize your point as a proposal to extend kstat framework
>> instead of providing filesy
> Just to echo Rich's comment, and a comment that others have made: I
> really don't want to see a pseudofilesystem become a dumping ground for
> machine information, in part because it makes for a terrible API. (Indeed,
> this proposal is almost identical to the ill-fated "MachFS" proposal of
>
Alexander Kolbasov wrote:
>> I'd like to modify my initial proposal and suggest to create a "CPU
>> Observability" project with the goal of providing good abstraction and
>> tools for CPU-related observability.
>>
>> As for the exact mechanism being used - the filesystem, programmatic
>> API, ksta
observability
>So are there any objections for creation of the CPU observability
project? I
think both performance and observability communities are a good home for
it.
Any strong preferences here?
This email and any files transmitted with it are confidential and intended
solely for the use
> I'd like to modify my initial proposal and suggest to create a "CPU
> Observability" project with the goal of providing good abstraction and
> tools for CPU-related observability.
>
> As for the exact mechanism being used - the filesystem, programmatic
> API, kstat extensions or some combinatio
[...]
> Hence, I totally agree with...
>
> >If a reasonably stable filesystem-like interface was
> available for
> >prtconf-like data, it would be easy to build tools
> which would look at
>
> >configuration and then subscribe to kstats to
> produce correlated
> >activities, just like prstat doe
G'Day Brian,
On Wed, Jul 11, 2007 at 03:05:14PM -0400, Brian Gupta wrote:
> How have I have gone all this time without knowing about the kstat command?!
> :(
There have been a number of really awsome tools that sadly haven't been
marketed or taught to customers very well; they would include,
Bruce Shaw wrote:
> I do have one concern, but perhaps I'm misunderstanding the chip architecture.
>
> module: cpu_info instance: 0
> name: socket1 class: socket
> brand AMD Galactic(tm) Processor 2000
> clock_MHz 6842
> cpu_type i386
> ...
>
> module: cpu_info instance: 0
> name: core0 class:
I do have one concern, but perhaps I'm misunderstanding the chip architecture.
module: cpu_info instance: 0
name: socket1 class: socket
brand AMD Galactic(tm) Processor 2000
clock_MHz 6842
cpu_type i386
...
module: cpu_info instance: 0
name: core0 class: core
clock_MHz 6842
! core_id 0
...
Why
BS> I want in on this. I use kstat to derive CPU information for
net-snmp.
BS> If we're opening the API, I've got some suggestions.
AK>what are your suggestions?
I got this about 2 minutes before quitting time, thought about it
overnight, then others chimed in overnight with excellen
How have I have gone all this time without knowing about the kstat command?!
:(
I have tried poking around, and am trying to understand some of the fields,
and have a couple of scriptlets that I wrote that should report identical
output. (As I understand)
What am I missing?
1) prtconf -v|grep ^
On Mon, Jul 09, 2007 at 11:14:18PM -0700, Alexander Kolbasov wrote:
> Hi Brendan,
>
> can I summarize your point as a proposal to extend kstat framework
> instead of providing filesystem-based representation for CPU-related
> information?
Yes, as a suggestion moving to a prototype. If this approa
On Jul 10, 2007, at 1:57 PM, Alexander Kolbasov wrote:
> I'd like to modify my initial proposal and suggest to create a "CPU
> Observability" project with the goal of providing good abstraction and
> tools for CPU-related observability.
>
> As for the exact mechanism being used - the filesystem, p
Bruce Shaw <[EMAIL PROTECTED]> wrote:
BS> I want in on this. I use kstat to derive CPU information for net-snmp.
BS> If we're opening the API, I've got some suggestions.
Bruce,
what are your suggestions?
- akolb
___
perf-discuss mailing list
>One question to consider is do we want to also
> support something similar to Linux's
> "/proc/cpuinfo"?
"something similar" might be up for discussion, but it's been
said before that unlike Linux, /proc on Solaris is _not_ a dumping
ground for every random piece of system info (worse yet, presen
On Tue, Jul 10, 2007 at 11:49:48AM -0600, Bruce Shaw wrote:
> >The kstat facility has long been in need of a serious overhaul; this
> >presents a good opportunity to do this work.
>
>
> I want in on this. I use kstat to derive CPU information for net-snmp.
> If we're opening the API, I've got s
>The kstat facility has long been in need of a serious overhaul; this
>presents a good opportunity to do this work.
> - Bryan
I want in on this. I use kstat to derive CPU information for net-snmp.
If we're opening the API, I've got some suggestions.
This email and any files transmitted wi
On Tue, Jul 10, 2007 at 10:57:17AM -0700, Alexander Kolbasov wrote:
> I'd like to modify my initial proposal and suggest to create a "CPU
> Observability" project with the goal of providing good abstraction and
> tools for CPU-related observability.
>
> As for the exact mechanism being used - the
I'd like to modify my initial proposal and suggest to create a "CPU
Observability" project with the goal of providing good abstraction and
tools for CPU-related observability.
As for the exact mechanism being used - the filesystem, programmatic
API, kstat extensions or some combination of these -
Hi Brendan,
can I summarize your point as a proposal to extend kstat framework
instead of providing filesystem-based representation for CPU-related
information?
Brendan Gregg - Sun Microsystems <[EMAIL PROTECTED]> wrote:
Brendan> G'Day Folks,
Brendan> On Mon, Jul 09, 2007 at 02:43:08PM
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 accessi
G'Day Folks,
On Mon, Jul 09, 2007 at 02:43:08PM -0700, Alexander Kolbasov wrote:
> > A related question is what is the best way to get configuration information
> > as opposed to performance information. For the kernel, most of the
> > performance data is separated out cleanly in kstats, but appli
>> 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 infrastruct
> 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 C
> A related question is what is the best way to get configuration information
> as opposed to performance information. For the kernel, most of the
> performance data is separated out cleanly in kstats, but applications
> still have constructs in /proc such as prusage, which contains the
> cpu usa
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.
> > T
> 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 fo
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
propert
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
30 matches
Mail list logo
