Date: Fri, 26 May 2000 23:58:26 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: cp@bsdi.com (Chuck Paterson) Cc: dillon@apollo.backplane.com (Matthew Dillon), tlambert@primenet.com (Terry Lambert), arch@freebsd.org Subject: Re: Preemptive kernel on older X86 hardware Message-ID: <200005262358.QAA23009@usr05.primenet.com> In-Reply-To: <200005250228.UAA16415@berserker.bsdi.com> from "Chuck Paterson" at May 24, 2000 08:28:00 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> We are seeing 30 clock ticks for a locked mutex > operation. Only 10 if you take out the lock for UP > systems. (hopefully I did the math right.) I just don't see how > putting a function call is going to be cheap relatively. > > Is it possible that you are hitting so many > spin locks that the function calltime gets burried. I've long been a fan of non-statistical profiling; I even implemented it for VxD profiling (using a modified gprof) under Windows. This uses "compiler magic" to put entry and exit functions in ever function; for it to be effective, you have to disable tail call optimization. The Microsoft compiler only generates an "entry" function, so you have to fudge the return code based on the caller data you get from the stack, so that if you know how to fudge it, then you push additional data on a seperate call return stack, and set the return code to point to your exit code instead. The return code then saves the return registers, records the (non-statistical) arc, puts the right stuff on the stack, and then returns again. Ugly, but it works. With source code for the compiler, we wouldn't have to screw around like this to get the same _real_, as opposed to statistical, data. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005262358.QAA23009>