Re: Giant instrumentation

On 23-Mar-2002 Robert Watson wrote:
> 
> On Thu, 21 Mar 2002, John Baldwin wrote:
> 
>> Kelly Yancey implemented most of the syscall Giant instrumentation stuff
>> I outlined in an earlier e-mail.  I have since mostly finished it and
>> changed a few things.  Most of the changes were design changes so that
>> the instrumentation stuff was as separated from the rest of the kernel
>> (and thus easily condionitionally compiled out with minimal impact) as
>> possible.  Also, it now provides better support for handling other ABIs. 
>> It's not complete yet (it only has instrumentation for the native ABI at
>> the moment) but I wanted to post this patch for feedback.  I have tested
>> it some and it is being tested some more on alpha and x86 at the moment. 
>> The patch can be found at: 
>> 
>> http://www.FreeBSD.org/~jhb/patches/giantvars.patch
> 
> (2) Question: how easily does this framework extend to trap handling, such
>     as VM traps where we might similarly want to be able to instrument
>     entry to traps that might or might not want Giant?  The current stuff
>     is pretty system-call specific in my reading, at least, in where it
>     gets the information.  Similarly, could this framework be adapted for
>     use with interrupt/driver entry points?

For trap handling, one could either use a static array in the various trap.c
filfes or just use the earlier mtx_lock_giant/mtx_unlock_giant API directly in
the code.  Trap handlers are not very wide spread and already have a single
point of exit for user traps.

> (4) One down-side to this approach is that it's not possible to push the
>     instrumentation point down below the system call level.  For example,
>     suppose we're confident that the first level code in the various
>     generic file descriptor-based calls is correct, but we want to
>     continue to instrument Giant over the VFS but not over pipes.  In such
>     a scenario, you could imagine something like the following:

Since this code is for debugging, it is my opinion that it does not need to be
as fine-grained and that a per-syscall granularity is sufficient.

-- 

John Baldwin <[e-mail]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [e-mail]
with "unsubscribe freebsd-smp" in the body of the message