Re: NCHNAMLEN vnode cache limitation removal

[christos%astron.com@localhost (Christos Zoulas)]

In article <20190913180602.GB20668%netbsd.org@localhost>,
David Holland  <dholland-tech%netbsd.org@localhost> wrote:
>On Wed, Sep 11, 2019 at 03:53:18PM +0700, Robert Elz wrote:
> > What's more interesting to me is to know just how many long names people
> > are seeing which are currently excluded from the cache, and would benefit
> > from the change - that is, what percentage of all lookups fail in the
> > cache for that reason, and do we have a histogram of the longer lengths
> > with their frequencies (that is, would simply making the cutoff a little
> > bigger improve things without requiring mem allocation to be added).
>
>The goal is to not arbitrarily exclude names from the cache at all,
>because fexecve is causing rumbles about doing significantly more
>reverse lookups.

I am going to run more tests with a bigger cache, but if you run:

    cc https://www.netbsd.org/~christos/countlen.c
    ./a.out /usr/src/ /usr/obj/ /usr/xsrc/

you'll see that there are still lots of names now > 32, so perhaps
making NCHNAMLEN 40 makes more sense this days (rather than 31
which was chosen ~40 years ago). Seems that people like longer
names as time goes forward. Also the way the code is now we can
make NCHNAMLEN a variable and use sysctl to change it (flushing
the cache), for quicker experiments that don't need recompiling.

But now we are not excluding anything; it is just that names over
NCHNAMLEN use kmem_alloc instead of pooled storage...

Best,

christos