From owner-freebsd-current Sat Jan 20 08:51:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA05095 for current-outgoing; Sat, 20 Jan 1996 08:51:52 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA05087 for ; Sat, 20 Jan 1996 08:51:37 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id DAA32632; Sun, 21 Jan 1996 03:48:45 +1100 Date: Sun, 21 Jan 1996 03:48:45 +1100 From: Bruce Evans Message-Id: <199601201648.DAA32632@godzilla.zeta.org.au> To: se@ZPR.Uni-Koeln.DE, toor@dyson.iquest.net 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 Cc: current@freebsd.org, dyson@freefall.freebsd.org Sender: owner-current@freebsd.org Precedence: bulk >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): 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