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
