From owner-freebsd-arch Fri May 26 16:58:53 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp09.phx.gblx.net (smtp09.phx.gblx.net [206.165.6.139]) by hub.freebsd.org (Postfix) with ESMTP id 742FF37B93D for ; Fri, 26 May 2000 16:58:49 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp09.phx.gblx.net (8.9.3/8.9.3) id QAA43492; Fri, 26 May 2000 16:58:42 -0700 Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp09.phx.gblx.net, id smtpdvRHMMa; Fri May 26 16:58:35 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA23009; Fri, 26 May 2000 16:58:26 -0700 (MST) From: Terry Lambert Message-Id: <200005262358.QAA23009@usr05.primenet.com> Subject: Re: Preemptive kernel on older X86 hardware To: cp@bsdi.com (Chuck Paterson) Date: Fri, 26 May 2000 23:58:26 +0000 (GMT) Cc: dillon@apollo.backplane.com (Matthew Dillon), tlambert@primenet.com (Terry Lambert), arch@freebsd.org In-Reply-To: <200005250228.UAA16415@berserker.bsdi.com> from "Chuck Paterson" at May 24, 2000 08:28:00 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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