Threads and userland profliing...

[Daniel Eischen]

On Wed, 12 May 2004, David Xu wrote:
> 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?

Yeah, I think so.  Anyone know what Linux does?

-- 
Dan Eischen