Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 17 Feb 2003 17:35:09 +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:  <20030217162950.B4682-100000@gamplex.bde.org>
In-Reply-To: <Pine.BSF.4.21.0302161812280.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:

> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030217162950.B4682-100000>