Date: Tue, 11 May 2004 17:59:37 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: John Baldwin <jhb@freebsd.org> Cc: Bruce Evans <bde@freebsd.org> Subject: Re: Threads and userland profliing... Message-ID: <Pine.GSO.4.10.10405111755490.11212-100000@pcnet5.pcnet.com> In-Reply-To: <200405111733.19783.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
--
Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10405111755490.11212-100000>