Threads and userland profliing...

[David Xu]

Daniel Eischen wrote:

>On Tue, 11 May 2004, John Baldwin wrote:
>
>  
>
>>Currently in the pstats structure we have a uprof substructure that holds 
>>various values used for userland processing.  Does anyone know what parts of 
>>that structure are supposed to be per-process and which are supposed to be 
>>per-thread?  pr_addr and pr_ticks seem to be definite per-thread items, but 
>>the other values I'm not sure of.
>>
>>Specifically, is the userland table that pr_base, pr_size, pr_off, and 
>>pr_scale refer to per-thread or is it supposed to be shared among all threads 
>>in a process?  If it's shared, do we need to be using casuptr() or something 
>>similar in addupc_intr() instead of a separate fetch and store?  
>>addupc_task() also has a race window between the copyin() and copyout() as 
>>well if it is shared.  If its private, then I suppose each thread has to call 
>>profil(2) and gprof is supposed to be smart enough to make that happen?  Does 
>>POSIX have anything to say regarding threads and profil(2)?
>>    
>>
>
>POSIX does not define profil(2).  Here's what Solaris 9 has to
>say about it:
>
>     In Solaris releases prior to 2.6, calling profil() in a mul-
>     tithreaded  program  would  impact only the calling LWP; the
>     profile state was not inherited at  LWP  creation  time.  To
>     profile  a  multithreaded  program  with  a  global  profile
>     buffer, each thread needed to issue a call  to  profil()  at
>     threads  start-up  time,  and  each thread had to be a bound
>     thread. This was  cumbersome  and  did  not  easily  support
>     dynamically  turning  profiling  on and off. In Solaris 2.6,
>     the profil() system call  for  multithreaded  processes  has
>     global  impact  -  that  is,  a call to profil() impacts all
>     LWPs/threads in the process.  This  may  cause  applications
>     that  depend  on the previous per-LWP semantic to break, but
>     it is expected to improve multithreaded programs  that  wish
>     to turn profiling on and off dynamically at runtime.
>
>We should probably avoid the mistake that Solaris < 2.6
>made.
>
>  
>
Because I never thought the profile buffer should be per-process,
did you mean that it should be per-process too?

David Xu