...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?
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.
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.
Jake
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
