Expanding vops in vop_vectors during startup

[Poul-Henning Kamp]

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
>  notable.
>
>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
sensible.

Furthermore, if I am not mistaken, your patch increases the kernel
size.

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
above.

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
objection:

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

-- 
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.