From owner-freebsd-threads@FreeBSD.ORG Tue May 11 15:36:55 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 48A1816A4CE; Tue, 11 May 2004 15:36:55 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E340543D1F; Tue, 11 May 2004 15:36:54 -0700 (PDT) (envelope-from davidxu@viatech.com.cn) Received: from viatech.com.cn (davidxu@localhost [127.0.0.1]) i4BMaq0i022595; Tue, 11 May 2004 15:36:53 -0700 (PDT) (envelope-from davidxu@viatech.com.cn) Message-ID: <40A15668.1030103@viatech.com.cn> Date: Wed, 12 May 2004 06:40:40 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031206 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Xu References: <40A15602.9020902@viatech.com.cn> In-Reply-To: <40A15602.9020902@viatech.com.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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:36:55 -0000 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, OOPS, I thought it should be per-process, not per-thread. > did you mean that it should be per-process too? > > David Xu > > > >