vfs cache timing changes

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

Hello,

Hi, so I did some timing tests before and after the vfs cache changes.

The original run for build.sh -j 80

    build.sh started:    Wed Sep 11 14:00:09 EDT 2019
    build.sh ended:      Wed Sep 11 16:48:03 EDT 2019
    2:47:54

Then I just moved name and nlen last and added the kmem_alloc for larger
allocations:

    # NCHNAMLEN=30 original order, name and nlen moved last.
    build.sh started:    Wed Sep 11 22:48:34 EDT 2019
    build.sh ended:      Thu Sep 12 01:54:20 EDT 2019
    3:06:46

This added 15 minutes to the build which sucks. I re-arranged things around
to move all the list members first:

    NCHNAMLEN=30 lists first, run1
    build.sh started:    Thu Sep 12 07:19:11 EDT 2019
    build.sh ended:      Thu Sep 12 10:15:49 EDT 2019
    2:56:38

It was better, then did a second run to see how much different it would be:

    NCHNAMLEN=30 lists first, run2
    build.sh started:    Thu Sep 12 10:32:32 EDT 2019
    build.sh ended:      Thu Sep 12 13:31:21 EDT 2019
    2:59:51

Not much different; still ~10 minutes slower. Then I noticed that we have
2 extra bytes available because of packing (to round to 160 bytes for _LP64
which was the original size) so I added that:

    NCHNAMLEN=32 lists first
    build.sh started:    Thu Sep 12 14:26:27 EDT 2019
    build.sh ended:      Thu Sep 12 17:10:51 EDT 2019
    2:44:36

Now we are approximately the same as before. I wonder how sensititive
this is to NCHNAMLEN. Anyway since there is no performance degradation
from the original I am planning to commit the changes and we can do
better later. I will commit the changes soon, unless there are objections.

Best,

christos

PS: The xz compression for the debug set takes 36 minutes on my machine.
We shoudl do something about it. Matt to use -T for more parallelism?