From owner-freebsd-current Thu May 29 09:41:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA25463 for current-outgoing; Thu, 29 May 1997 09:41:47 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA25456 for ; Thu, 29 May 1997 09:41:43 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id CAA20635; Fri, 30 May 1997 02:36:44 +1000 Date: Fri, 30 May 1997 02:36:44 +1000 From: Bruce Evans Message-Id: <199705291636.CAA20635@godzilla.zeta.org.au> To: bde@zeta.org.au, phk@dk.tfs.com Subject: Re: disk cache challenged by small block sizes Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>ufs with a block size of 4K was about the same speed as ext2fs with a block >>size of 4K. ufs with a block size of 8K was significantly (25%) slower. > =========================================================== > >Uhm, isn't that rather obvious ? No :-). >The chances of being able to do one DMA into two (physically) consecutive >pages are very very slim as far as I can tell, so you will generally get >better performance when you do it in page size chunks ? The pages are normally discontiguous, so they are normally done in page- size chunks. A block size of 8K should allow better disk scheduling. Read-ahead is based in the principle of sending even larger requests to the driver. These times for raw i/o show that the OS's cache is doing something right to get even 700K/sec. Speeds in bytes/sec for dd'ing 512 blocks to/from /dev/zero: block size read write 512 24940 24940 1024 49643 49642 2048 98336 98145 4096 191187 191186 8192 321249 321247 16384 518759 519419 32768 730492 732447 65536 894033 896461 Bruce