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:  [EMAIL PROTECTED]
Nonlinear Systems Ltd.                  Phone: +44 20 8442 9037

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to