From owner-freebsd-threads@FreeBSD.ORG Tue May 11 14:59:39 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 5D69316A4CE; Tue, 11 May 2004 14:59:39 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 813A943D1F; Tue, 11 May 2004 14:59:38 -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 i4BLxbke012044; Tue, 11 May 2004 17:59:37 -0400 (EDT) Date: Tue, 11 May 2004 17:59:37 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: John Baldwin In-Reply-To: <200405111733.19783.jhb@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: Bruce Evans 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 21:59:39 -0000 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