Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 01 Oct 2008 19:46:55 +0000
From:      "Poul-Henning Kamp" <phk@phk.freebsd.dk>
To:        Ed Schouten <ed@80386.nl>
Cc:        FreeBSD FS <freebsd-fs@freebsd.org>, Mark van Cuijk <mark@van-cuijk.nl>, Jille Timmermans <jille@quis.cx>, FreeBSD Arch <freebsd-arch@freebsd.org>
Subject:   Re: Expanding vops in vop_vectors during startup 
Message-ID:  <69186.1222890415@critter.freebsd.dk>
In-Reply-To: Your message of "Wed, 01 Oct 2008 21:07:28 %2B0200." <20081001190728.GL16837@hoeg.nl> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <20081001190728.GL16837@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@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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?69186.1222890415>