From owner-freebsd-threads@FreeBSD.ORG Tue May 11 15:47:43 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB6BD16A4CE; Tue, 11 May 2004 15:47:43 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48AED43D2F; Tue, 11 May 2004 15:47:43 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i4BMlgke025596; Tue, 11 May 2004 18:47:42 -0400 (EDT) Date: Tue, 11 May 2004 18:47:40 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: David Xu In-Reply-To: <40A15602.9020902@viatech.com.cn> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: Bruce Evans cc: John Baldwin Subject: Re: Threads and userland profliing... X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2004 22:47:44 -0000 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