From owner-freebsd-current Fri Apr 28 1: 7:47 2000 Delivered-To: freebsd-current@freebsd.org Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by hub.freebsd.org (Postfix) with ESMTP id 173BD37B7CD for ; Fri, 28 Apr 2000 01:07:44 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1) id 12l5oJ-000D9M-0Y; Fri, 28 Apr 2000 09:07:42 +0100 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA48163; Fri, 28 Apr 2000 09:07:55 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Fri, 28 Apr 2000 09:12:27 +0100 (BST) From: Doug Rabson To: Jake Burkholder Cc: Bruce Evans , Boris Popov , freebsd-current@FreeBSD.ORG Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: <20000427204341.9648DBCA7@io.yi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 27 Apr 2000, Jake Burkholder wrote: > ...snip... > > > > Its nice to see someone actually using kobj so soon. There is a possible > > performance problem though - kobj method calls are roughly 20% slower than > > direct function calls. Having said that, this isn't that slow - I timed a > > method call to a two argument function at ~40ns on a 300MHz PII. > > > > I could improve this for some applications (including this one) by > > providing a mechanism for an application to cache the function pointer > > returned by the method lookup. > > Yes, this sounds interesting. I can see that there are provisions for a > cache in the code, and I can see from the sysctls that hits and misses > are happening, but I can't see where the function pointers are entered > into the cache. Is this enabled by default? This is enabled by default. The address of the cache entry is passed as the second argument to kobj_lookup_method(). > > It also might be possible to have default implementations that do > "less than nothing", a special value could be entered in the cache that > indicates don't call through the function pointer at all. I don't know > how an inline cache lookup would compare to an empty function call, > but it might be a win when the locks are supposed to do nothing. Thats an interesting thought. It would add a compare and branch to the normal method dispatch case which might be too high a cost. > > Anyway, I've made a patch that uses Boris's suggestion of providing > functions with empty bodies. I worry about optimizing for the static UP > kernel because of introducing more SMP and KLD_MODULE ifdefs, possibly it > should just be a function call in all cases. > > http://io.yi.org/lock.diff > > I will send-pr it if no one has any comments. It looks quite reasonable to me. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message