dtrace discuss - Jun 2006 - Extending lwpsinfo_t with pr_lgrp for DTrace consumers

The sched provider defines the stable "lgrp" variable that is the
lgroup of
the current CPU. This is mostly interesting when we can compare it with the 
actual thread home lgroup, so I''d like to extend the lwpsinfo_t
structure with
the new pr_lgrp field which will be implemented using translator. This will 
match the addition of the pr_lgrp field to the proc(4) lwpsinfo_t structure
that is done with the NUMA observability changes (it utilises one of the five 
reserved fields).

The pr_lgrp field will only be available for consumers with dtrace_kernel 
privilege since the translator needs to do kernel pointer dereference.

This change allows simple script to get lgroup migration statistics, e.g.

sched:::on-cpu
/execname != "sched" && curlwpsinfo->pr_lgrp != lgrp/
{
     @[execname, curlwpsinfo->pr_lgrp] = count();
}

snmpd                                               3                1
utmpd                                               1                1
automountd                                          2                2
intrd                                               2                3
dtrace                                              2                4
fmd                                                 1               12



I have a few questions related to this proposed change:

- Are there any objections to this change?

- Are there any stability levels associated with specific fields of lwpsinfo_t 
  for DTrace consumers?

- What parts of the documentation are affected by this change other than the 
  DTrace guide?

- Is there any embedded DTrace knowledge of lwpsinfo_t fields other than in 
  sched.d? 


__
Alex Kolbasov
http://blogs.sun.com/akolb

On Tue, Jun 20, 2006 at 01:01:42PM -0700, Alexander Kolbasov
wrote:
> The sched provider defines the stable "lgrp" variable that is the
> lgroup of the current CPU. This is mostly interesting when we can
> compare it with the actual thread home lgroup, so I''d like to
extend
> the lwpsinfo_t structure with the new pr_lgrp field which will be
> implemented using translator. This will match the addition of the
> pr_lgrp field to the proc(4) lwpsinfo_t structure that is done with
> the NUMA observability changes (it utilises one of the five reserved
> fields).
> 
> The pr_lgrp field will only be available for consumers with dtrace_kernel 
> privilege since the translator needs to do kernel pointer dereference.
> 
> This change allows simple script to get lgroup migration statistics, e.g.
> 
> sched:::on-cpu
> /execname != "sched" && curlwpsinfo->pr_lgrp != lgrp/
> {
>      @[execname, curlwpsinfo->pr_lgrp] = count();
> }
> 
> snmpd                                               3                1
> utmpd                                               1                1
> automountd                                          2                2
> intrd                                               2                3
> dtrace                                              2                4
> fmd                                                 1               12
> 
> 
> 
> I have a few questions related to this proposed change:
> 
> - Are there any objections to this change?
Sounds reasonable to me, as long as this goes back at the same time (or later)
as the NUMA observability work.
> - Are there any stability levels associated with specific fields of
> lwpsinfo_t for DTrace consumers?
I believe they are considered Stable, to match proc(4).
> - What parts of the documentation are affected by this change other than
the
>   DTrace guide?
Just the dtrace guide, as far as I know.
> - Is there any embedded DTrace knowledge of lwpsinfo_t fields other than in
>   sched.d? 
Nope;  it''s all in sched.d.

Cheers,
- jonathan

-- 
Jonathan Adams, Solaris Kernel Development