From owner-freebsd-hackers  Sun Apr 14 16:55:40 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id QAA23698
          for hackers-outgoing; Sun, 14 Apr 1996 16:55:40 -0700 (PDT)
Received: from Root.COM (implode.Root.COM [198.145.90.17])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA23689
          Sun, 14 Apr 1996 16:55:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by Root.COM (8.7.5/8.6.5) with SMTP id QAA04357; Sun, 14 Apr 1996 16:55:34 -0700 (PDT)
Message-Id: <199604142355.QAA04357@Root.COM>
X-Authentication-Warning: implode.Root.COM: Host localhost [127.0.0.1] didn't use HELO protocol
To: dyson@FreeBSD.org
cc: andreas@knobel.gun.de (Andreas Klemm), joerg_wunsch@uriah.heep.sax.de,
        groudier@iplus.fr, hackers@FreeBSD.org, linux-kernel@vger.rutgers.edu
Subject: Re: Unices are created equal, but ... 
In-reply-to: Your message of "Sun, 14 Apr 1996 18:22:20 CDT."
             <199604142322.SAA00427@dyson.iquest.net> 
From: David Greenman <davidg@Root.COM>
Reply-To: davidg@Root.COM
Date: Sun, 14 Apr 1996 16:55:34 -0700
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

>> Whole Linux seems to be a memory file system ;-) They are caching
>> like hell. Only benchmarks like bonnie on files of about 3xRAMSIZE
>> address the fact that we want to bench the disk and not the RAM.
>> Gerard compares chicken with eggs. This Byte Bench is really
>> questionable.
>>
>The most evil things about aggressively write cache are the memory starvation
>and sync issues.  On FreeBSD we purposely decided to limit the amount of
>dirty cached file data.  It can become a real problem with big memory
>systems!!!  The AT&T GIS/NCR/Tandem boxes really acted badly when users
>would tune the system to allow too much memory to be dirty filesystem
>cache buffers.  I could be convinced that 1/4 of memory for dirty buffers
>is okay, and in some cases even more could be considered.  But those cases
>where a system could gain significantly from huge write caches are few
>and far between.  I guess if managed VERY WELL, a large (>1/2 mem) write cache
>would be good -- I just haven't seen that yet.

   Worst case, that would be about 256MB of cached data to write out on
wcarchive. :-) I think I prefer the current scheme. :-)

-DG

David Greenman
Core-team/Principal Architect, The FreeBSD Project