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?
