From owner-freebsd-current Sun Feb 16 23:30:58 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 6DFDB37B401 for ; Sun, 16 Feb 2003 23:30:56 -0800 (PST) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 781C143F85 for ; Sun, 16 Feb 2003 23:30:55 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc01.attbi.com (sccrmhc01) with ESMTP id <20030217073053001004vr25e>; Mon, 17 Feb 2003 07:30:54 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA09806; Sun, 16 Feb 2003 23:30:51 -0800 (PST) Date: Sun, 16 Feb 2003 23:30:50 -0800 (PST) From: Julian Elischer To: Bruce Evans Cc: FreeBSD current users Subject: Re: question on profiling code In-Reply-To: <20030217162950.B4682-100000@gamplex.bde.org> Message-ID: 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 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. > > > is there any reason that the address of the PC needs to be stored? > > why is the address from the frame at that time not useable? > > > > is it because the PC in the return frame may be hacked up for signals? > > That's was good a reason as any. I think the next return to user mode > is to the signal handler's context (if there is a signal to be handled). > It would be wrong to use the signal handler's pc. 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. > This probably doesn't matter much, since signals are > rare and the hitting on the signal handler's pc would be perfectly > correct if the profiling interrupt occurred an instant later. that is true. > > 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?) > > Bruce > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message