Philip,

thank you for your comments!

> I have to echo the other positive comments about the lgrp tools. It's
> shedding light on a whole area which has previously been difficult to
> appreciate. The ideal would be to get some idea via the tools of the latency
> penalty of accessing pages across groups [is the group configuration just
> statically configured somewhere? If so, could this info be a part of that?],

You can get the latency information using lgrpinfo -l command. This will 
extract the latency table from the kernel. Note that these latencies are just 
approximation of the real node-to-memory latencies, but they do give idea of
relative latencies. On sparc systems these latencies are static but on x86 
system the system does some probing at boot time.

> and the logical next step is the amount of time my app is spending waiting
> to access those pages - but obviously that's a way off.

This is a hard problem...
 
> And one specific point...
> 
> >  - "plgrp -G <pid>" returns a number plus an extra blank 
> > line.  Why the 
> > blank line?  bug? feature?
> > - Can you add a flag to up the verbosity?  Getting just the 
> > lgroup ID 
> > back is handy, 
> 
> I sort-of agree; the first one of these tools I ran was plgrp, and whilst
> it's my fault for not reading the docs, I initially wondered just what that
> number was (if you're new to this stuff you could conceivably think it's a
> CPU id or something). Maybe just a couple of words like "Home lgrp: " (sorry
> if the terminology's a bit off) in front of it would make it clearer. If the
> terseness is intentional (I can see it would make scripting easier) feel
> free to ignore!

We may consider two modes - human-readable and tense outputs for automatic 
parsing.
 
> Getting a bit radical for a minute - with (for example) psrset I can get
> hold of _all_ processor set bindings using psrset -q. I think it would be
> useful to be able to get home lgrp information across a number of processes;
> it's probably not the right place for it, but I'm imagining something like
> being able to specify the home lgrp as an output column on ps(1).

Probably plgrp is not the right place for it, but we are considering extending 
ps(1) and prstat(1) so that you can see home lgroups using familiar tools.
Is it what you are looking for?

- Alexander Kolbasov.



_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org

Reply via email to