Date: Tue, 18 Feb 2003 08:54:59 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Jake Burkholder <jake@locore.ca> Cc: Julian Elischer <julian@elischer.org>, FreeBSD current users <current@FreeBSD.ORG> Subject: Re: question on profiling code Message-ID: <20030218075519.Y7132-100000@gamplex.bde.org> In-Reply-To: <20030217021512.O63597@locore.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 17 Feb 2003, Jake Burkholder wrote: > Apparently, On Mon, Feb 17, 2003 at 05:35:09PM +1100, > Bruce Evans said words to the effect of; > > ... 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. > > There are macros for accessing trapframes, like the ones for clockframe, > TRAPF_PC etc. Oops. ast() always had a frame, and it needed and got some frame access macros when it was MI'ized. > > 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. > > In freebsd "fast" interrupts do handle asts, on i386 they return through > doreti Oops. > (you may consider this a bug and have removed it in your version). Indeed I have (my version never had it). This doesn't result cause the problem that I thought we had (of not updating the user profiling counter as soon as possible) since my hardclock() and statclock() aren't fast interrupt handlers. However, using ithreads causes similar problems stashing the pc. My sched_ithd() saves the pc and other relevant state for the the ithreads to look at later, much like addupc_intr() saves things. > I see no reason not to just use the pc in the trapframe passed to ast, > even in the case of signals they won't be posted until after addupc_task > is called. I think this would work even in my version. The pc for a clock interrupt in kernel mode is more interesting in my version, but the pc for a clock interrupt from user mode must be the same one as in the user's trapframe except for the special case of signal handling. Can you explain how fuswintr() and suswintr() work on sparc64's? They seem to cause traps if the user counter is not mapped, and I can't see where the traps are handled. ia64/trap.c has a comment about where these traps are handled, but has dummies for fuswintr() and suswintr() so the traps never occur. Depending on traps in fast interrupt handlers is a bug IMO. It extends the scope of the fast interrupt handler to the trap handler, and it is difficult to limit this scope and verify the locking for it. Bruce 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?20030218075519.Y7132-100000>