Date: Mon, 25 Mar 2002 11:40:18 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: smp@FreeBSD.org Subject: Re: Giant instrumentation Message-ID: <XFMail.20020325114018.jhb@FreeBSD.org> In-Reply-To: <Pine.NEB.3.96L.1020322213642.47668A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20020325114018.jhb>