From owner-freebsd-current Sun Feb 16 22:34:37 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 C635637B401 for ; Sun, 16 Feb 2003 22:34:35 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9823143F3F for ; Sun, 16 Feb 2003 22:34:34 -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 RAA07277; Mon, 17 Feb 2003 17:34:27 +1100 Date: Mon, 17 Feb 2003 17:35:09 +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: <20030217162950.B4682-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: > 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. > 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, and there is no macro like CLKF_PC() for general frames. 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. 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 unother 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. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message