From owner-freebsd-hackers Sun Aug 19 17: 6:54 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id A5BEA37B407; Sun, 19 Aug 2001 17:06:48 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f7K06VK47176; Sun, 19 Aug 2001 17:06:31 -0700 (PDT) (envelope-from dillon) Date: Sun, 19 Aug 2001 17:06:31 -0700 (PDT) From: Matt Dillon Message-Id: <200108200006.f7K06VK47176@earth.backplane.com> To: Rik van Riel Cc: David Greenman , Sergey Babkin , , , Subject: Re: Recommendation for minor KVM adjustments for the release References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> Yes, and the buffer cache determines how much dirty file-backed data :> (via write() or mmap()) the system is allowed to accumulate before :> it forces it out, which should probably be the greater concern here. : :How hard would it be to allow dirty data in the file :cache, without buffer mappings ? : :regards, : :Rik This is already supported via MAP_NOSYNC. The problem is that the dirty data is not tracked under light memory loads (tracking dirty data is a function of the buffer cache), so unless something forces the page out or fsync()s the file explicitly, the dirty data might not be written out for days. It might look good in a benchmark, but it would play havoc on system stability in the event of a crash. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message