Date: Wed, 12 May 2004 06:38:58 +0800 From: David Xu <davidxu@viatech.com.cn> To: Daniel Eischen <eischen@vigrid.com> Cc: John Baldwin <jhb@freebsd.org> Subject: Re: Threads and userland profliing... Message-ID: <40A15602.9020902@viatech.com.cn> In-Reply-To: <Pine.GSO.4.10.10405111755490.11212-100000@pcnet5.pcnet.com> References: <Pine.GSO.4.10.10405111755490.11212-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40A15602.9020902>