From owner-freebsd-current Mon Feb 17 14:11:46 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B01D737B401 for ; Mon, 17 Feb 2003 14:11:44 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF0C443F85 for ; Mon, 17 Feb 2003 14:11:43 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id JAA11813; Tue, 18 Feb 2003 09:11:36 +1100 Date: Tue, 18 Feb 2003 09:12:21 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Julian Elischer Cc: FreeBSD current users Subject: Re: question on profiling code In-Reply-To: Message-ID: <20030218085508.J7132-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 16 Feb 2003, Julian Elischer wrote: > On Mon, 17 Feb 2003, Bruce Evans wrote: > > > On Sun, 16 Feb 2003, Julian Elischer wrote: > > > > > In addupc_intr, if the increment cannot be done immediatly, the addres > > > to increment the count for is stored and the increment is done later at > > > ast or userret() time... > > > > Note that "cannot be done immediatly" is "always except on sparc64's" > > under FreeBSD, since incrementing the counter immediately is only > > implemented on sparc64's. > > Care to explain this statement? > It doesn't corelate what I see in addupc_int() > which is Machine Independent. addupc_intr() calls the MD functions fuswintr() and suswintr() to do most of the work (if possible), and these functions are dummies which find it impossible to do the work on all arches except sparc64. > > .... Also, ast() doesn't > > have access to the frame, > > funny, it uses it.. > > > and there is no macro like CLKF_PC() for > > general frames. > > They seem to be the same. Macro or no macro, ast and userret can > certainly access the return address. I misremembered this. See another reply for more details. > > Now there is a stronger reason: clock interrupt handling is "fast", > > so it normally returns to user mode without going near ast(), and the > > counter is not updated until the next non-fast interrupt or syscall. > > This might not happen until another profiling interrupt clobbers the > > saved pc, not to mention the saved tick count (it could just increment > > the tick count so that ticks are assigned to the last saved pc instead > > of lost; currently, the tick count mostly just tracks KEF_OWEUPC so > > it need not be saved). This was broken by SMPng (hardclock() is not > > really a fast interrupt handler but is abused as one). However, normal > > applications probably make enough syscalls to get the right counter > > updated, provided we use the counter for the pc at fast interrupt time > > and not the counter for the pc later. > > I'm trying to fix this for multithreaded programs.. > thanks for the answer.. I hadn't considered that reason. > I assumed that the ASTPENDIG flag would be set, and that > the AST would happen, (the userret certainly happens). > (does it not?) I was wrong here too. AST's happen soon even in the fast interrupt case except in my version (where this is moot because fast interrupt handlers can't schule ASTs). As I understand it, what you want to do is remove pr_addr and pr_ticks because these were never needed before KSE and just get in the way for KSE (they would have to be per-thread and then their redudancy would be more bogus). I agree with trying this. Brcause To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message