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 excellent suggestions
similar to what I was thinking about.
My main focus was going to be on ease of access to information vs. the
resources required to generate it and I'm thinking of the "little guy"
with a small number of cores. Hence I would want to strike the correct
balance of hierarchy of socket->core->thread such as in Brendan Gregg's
sample CPU layout, but I'm worried about the resources required (and the
time taken) to walk that tree looking for a specific value. Granted,
for my specific application, I'm more interested in cpu_info class misc
which is lower in the tree.
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 does with processes and projects.
...both because the API might be simpler and the process itself may take
less resources.
I'll respond to individual concerns in their own threads.
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed. If
you have received this email in error please notify the system manager. This
message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail.
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
