Expanding vops in vop_vectors during startup
phk at phk.freebsd.dk
Wed Oct 1 19:47:00 UTC 2008
In message <20081001190728.GL16837 at hoeg.nl>, Ed Schouten writes:
>The reason I'm sending this message, is because based on discussions I
>had with several people on IRC we've basically got two different
>opinions on this patch:
>- One group of people liked the idea of the patch. Some people even said
> the patch looks good enough to be committed.
>- Another group of people also liked the idea, but thought it would make
> no sense to commit it, because it's not like it's a bottleneck right
> now. It should only be committed if an increase in performance is
>I did some tests with the patch set, by running tens of millions of
>fstat(), fchown(), etc. calls to see how performance was affected. It
>turns out on a kernel without any debugging options enabled, the
>performance gain is only 1-2%, which sounds pretty valid to me.
My resistance to this patch is not quite what you describe above:
By factoring the vop vectors out, you remove the ability to let
default vectors pick up new functionality later.
I will admit that I have no knowledge of this level of generality,
dating back from Heidemans Phd. dissertation, being used for anything
Furthermore, if I am not mistaken, your patch increases the kernel
Absent a plausible performance improvement, I don't see any point
of your change.
And that brings me to your "1-2%" measurement quoted in IRC and
I have earlier ranted about the difference between benchmarking
and random number generators, and you may have joined the project
after the latest of these.
Please search the mail-archives for that topic, and then use
the handy ministat(1) program, to see if you have actually
show any net speed benefit.
Once and if you cross that threshold, I am going to raise my next
Benchmarking "tens of millions of fstat(), fchown(), etc. calls"
and showing a 1-2% difference is patently bogus, and certainly
no reason for the change you propose.
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
More information about the freebsd-fs