From owner-freebsd-stable Wed Apr 26 20:49: 1 2000 Delivered-To: freebsd-stable@freebsd.org Received: from wat-border.sentex.ca (waterloo-hespler.sentex.ca [199.212.135.66]) by hub.freebsd.org (Postfix) with ESMTP id 998C737B781; Wed, 26 Apr 2000 20:48:56 -0700 (PDT) (envelope-from mike@sentex.net) Received: from granite.sentex.net (granite-atm.sentex.ca [209.112.4.1]) by wat-border.sentex.ca (8.9.3/8.9.3) with ESMTP id XAA75466; Wed, 26 Apr 2000 23:48:55 -0400 (EDT) (envelope-from mike@sentex.net) Received: from chimp (ospf-mdt.sentex.net [205.211.164.81]) by granite.sentex.net (8.8.8/8.6.9) with ESMTP id XAA11636; Wed, 26 Apr 2000 23:48:54 -0400 (EDT) Message-Id: <4.2.2.20000426234307.0342e878@mail.sentex.net> X-Sender: mdtancsa@mail.sentex.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 26 Apr 2000 23:47:44 -0400 To: Matt Dillon From: Mike Tancsa Subject: Re: cvs commit: src/sys/gnu/ext2fs ..... Cc: stable@FreeBSD.ORG In-Reply-To: <200004262036.NAA81630@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 01:36 PM 4/26/2000 -0700, Matt Dillon wrote: >dillon 2000/04/26 13:36:37 PDT > MFC sequential write detection heuristic. This extends the sequential > read heuristic to also cover sequential writes, causing write-behind > to be used only for the sequential write case. This solves a number of > performance issues with random writes to medium sized files using > large block sizes, as occurs with DBM files. Well, it does seem to make a difference for me. I was building another box, and decided to try out a 'before' and after. The first is from a stable box from the AM, the second with the above commit. -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 500 17721 84.5 18474 34.8 6166 12.4 14853 97.6 25036 30.6 110.7 2.0 500 17566 82.9 18419 35.0 8301 16.9 14885 97.1 25014 20.5 108.2 1.6 Sure enough, an increase in the rewrite performance on the drive.... The other differences are most likely statistically insignificant, but the rewrite does seem to be valid. Way to go! drive is a ad1: 39082MB [79406/16/63] at ata0-slave using UDMA33 on a Intel PIIX4 ATA33 controller ---Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message