Date: Tue, 18 Feb 2003 09:12:21 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Julian Elischer <julian@elischer.org> Cc: FreeBSD current users <current@FreeBSD.ORG> Subject: Re: question on profiling code Message-ID: <20030218085508.J7132-100000@gamplex.bde.org> In-Reply-To: <Pine.BSF.4.21.0302162317390.99373-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030218085508.J7132-100000>