Possible evidence of performance regression for 8.1-S (vs. 7.1)

[Ivan Voras]

On 10/26/10 19:45, David Wolfskill wrote:
> On Tue, Oct 26, 2010 at 02:03:34PM +0200, Ivan Voras wrote:
>> ...
>> Since you now have the two kernels readily available, can you rule out
>> NFS by just repeating the step which involves it in both kernels and
>> compare the results?
> 
> On Tue, Oct 26, 2010 at 02:47:11PM +0200, Ivan Voras wrote:
>> ...
>> Couldn't you simply run blogbench or just copy/untar a full /usr/ports
>> tree on NFS that while booting either of the kernels?
> 
> OK; here are timing results from 5 iterations each of running "tar
> xf", reading aa gzipped tarball of /usr/ports (updated earlier this
> morning) from NFS & writing it to the same local file system that
> I used for the previously-cited builds.  Each of these was run on
> the 8.x reference machine, and each terminated with a status code of 0:
> 
>      start        stop    real   user    sys  os
> 1288111167  1288111298  131.14  12.77  17.88  7.1-R+

> 1288109542  1288109653  111.26  12.03  14.88  8.1-S [7.1-R+ userland]

> 1288112673  1288112768   94.88   9.41  12.87  8.1-S

There's a slight problem here: 8.1 with 7.1 userland should, in this
test, behave the same as 8.1 with 8.1 userland. There have been no
breakthroughs in gzip decompression or compiler optimization between
those two releases that would make 8.1 userland faster.

The most probable cause for the difference is simply disk drive location
- inner vs outer tracks (you can run diskinfo -vt on the drive - it's
non-destructive). This may also be the cause for your originally noticed
speed difference.

You could try some IO tuning on the box with sysctls like:

vfs.hirunningspace=8388608
vfs.lorunningspace=6291456
vfs.ufs.dirhash_maxmem=8388608
vfs.read_max=32

... but if the problem is due to the disk track locations, it's not
really a problem.