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 -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 applications
>> > still have constructs in /proc such as prusage, which contains the
>> > cpu usage (derived from the days of BSD), over and above
>> > /proc/pid/status and the like.
>> >
>> > Is it legitimate to says /CPUfs is to be primarily or entirely
configuration?
>>
>> There is no particular reason why CPufs should be limited to
configuration
>> information - it seems to be a perfectly valid place for some of the
>> performance characteristics as well.
Brendan> Except that it would duplicate CPU performance stats from
Brendan> kstat.
I think that we can we should be able to agree on what performance data
belongs where. While kstats are fine for representing individual CPUs
load, for example, things become more interesting when we want to
observe per-socket or per-core load. Should we create kstats for each of
these entities? How would we discover which ones are relevant? How could
we know by just looking at kstats what is shared by what? How would we
correlate kstats with Processor Group abstraction?
Brendan> As an end-user of performance stats, I'd rather see kstat enhanced
Brendan> with meaningful and stable information, rather than new interfaces
Brendan> created. Unless it could be shown that doing this in kstat is
really dumb.
Brendan> Exactly how ugly would it be to represent this information
Brendan> in kstat?
IMO kstats are fine for what they do, but using them for extracting
system configuration is quite a bit of a stretch. Kstats are nice for
representing simple flat namespaces. Try expressing sharing between
CPUs, caches, cores, etc. using kstats and showing which CPUs share L3.
It can quickly become quite ugly. Then tools like psrinfo need to
understand enough of intricate details to translate it reasonably in
user-readable form and it is hard to maintain in a way that doesn't
break it with future extensions in the CPU technology. For example, how
much should psrinfo (or a similar kstat user-land parser) know about
caches, cores and sockets?
Brendan> You could argue that controller/disk/partition is a similar
hierarchy with
Brendan> shared resources (eg, partitions share the on-disk cache and
bandwidth),
Brendan> yet that works just fine from kstat, and could be extended to work
Brendan> even better (eg, on-disk cache size would appear in class:disk,
assuming
Brendan> that value is readable; partitions could have a statistic to
identify
Brendan> which disk they belonged to, if it wasn't already obvious
Brendan> from the name).
While there are some analogies, I suspect that with CPUs in the CMT
world we are dealing with issues different from those in the disk world.
How are disk hierarchies represented in kstats?
Brendan> cheers,
Brendan> Brendan
- akolb
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
