Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 21 Jan 1996 03:48:45 +1100
From:      Bruce Evans <bde@zeta.org.au>
To:        se@ZPR.Uni-Koeln.DE, toor@dyson.iquest.net
Cc:        current@freebsd.org, dyson@freefall.freebsd.org
Subject:   Re: cvs commit: src/sys/vm default_pager.c device_pager.c swap_pager.c vm_fault.c vm_glue.c vm_kern.c vm_map.c vm_map.h vm_mmap.R
Message-ID:  <199601201648.DAA32632@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>I am including -current in the distribution so that others might give
>the code a try and find out if things have gotten slower (maybe get
>it fixed ASAP!!!)

>> 
>> These changes seem to have made the file system performance
>> much lower than it used to be. I assume that FS clustering 
>> doesn't work as before:
>> 
>>               -------Sequential Output-------- ---Sequential Input-- --Random--
>>               -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
>> Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
>> before    100  1532 98.2  6154 67.6  2781 56.9  1664 98.6  6224 74.1  79.2  9.1
>> after     100  1501 98.0  3337 29.7  1337 22.6  1225 80.0  3402 36.2  77.3  8.4

I've lost a factor of 2 for reads:

              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
before(1) 128  1379 96.8  1769 22.9   726 15.7  1507 95.6  2018 27.6  34.4  4.6
after(1)  128  1396 96.9  1745 19.3   693 12.6   772 45.3  1170 15.9  35.4  4.5
before(2) 128  1334 97.8  3095 42.8  1238 26.8  1507 97.8  3357 46.0  52.7  7.2
after(2)  128  1407 98.2  3104 37.7  1094 19.4   960 56.2  1664 22.4  55.0  6.9
before(3)  24   592 71.3  1287 17.5   513 11.4   661 71.0  1275 15.4  40.0  6.1
after(3)   24   599 71.8  1306 16.2   380  8.8   467 51.2   974 13.5  40.2  5.7

before: kernel-Jan14
after:  kernel-Jan20 (current)
(1):    486DX2/66 VLB BT445c
	(bt0:0:0): "TOSHIBA MK537FB/ 6258" type 0 fixed SCSI 2
        sd0(bt0:0:0): Direct-Access 1015MB (2079838 512 byte sectors)
(2):    486DX2/66 VLB BT445c
        (bt0:3:0): "QUANTUM XP34301 102C" type 0 fixed SCSI 2
        sd1(bt0:3:0): Direct-Access 4106MB (8410200 512 byte sectors)
(3):    486DX/33 ISA IDE
        wdc0: unit 0 (wd0): <SAMSUNG SHD-3212A (APOLLO-4) AD>
        wd0: 407MB (833664 sectors), 1002 cyls, 16 heads, 52 S/T, 512 B/S

>There should have been NO change in write performance other than less code
>is being executed.   Read performance might be *very very* slightly decreased,

The removal of non-write-through for the async case affects write
performance significantly.  It should make little difference for
large sequential writes and be extremely harmful for randow writes.
However, it seems decrease the performance of large sequential writes
a lot in practice (I think because blocks are written in the wrong
order and/or with the wrong timing).

Bruce



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