From owner-freebsd-hackers Thu Jan 7 20:53:57 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA00854 for freebsd-hackers-outgoing; Thu, 7 Jan 1999 20:53:57 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA00849 for ; Thu, 7 Jan 1999 20:53:56 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id UAA37668; Thu, 7 Jan 1999 20:53:25 -0800 (PST) (envelope-from dillon) Date: Thu, 7 Jan 1999 20:53:25 -0800 (PST) From: Matthew Dillon Message-Id: <199901080453.UAA37668@apollo.backplane.com> To: Alfred Perlstein Cc: Terry Lambert , dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :> Which buffer? The one MFS passed back or the original one that was :> replaced? I assume you mean that the original buffer is freed and :> we are now talking about the one MFS passed back, currently under :> control of FFS, is no longer being used and eventually is ready :> to be freed again. : :Yes, I just thought of a simple idea that may make this a reality, ALL :pages returned by MFS are marked dirty so that they are 'flushed' to the :MFS disk no matter what. : :Really nothing is done except the fact that the FFS can not 'steal' pages :from the MFS and try to reuse them because they DO belong to the MFS. : :Just an idea for zero copy. (well single copy, kernel to process, instead :of kernel to kernel to process) Ick. We can't just mark them dirty, it would cost too much. The most common filesystem operation is a read. We do not want to force reads to generate writes back out to swap, which is what marking the page dirty would do. :> from the upper VFS layer, but the fact that the lower VFS layer is :> removing the page from its own map and thus 'looses' track of it - :> something a vm_alias would solve neatly. : :I'm not arguing against your proposals. What I understand I find very :appealing, I just had an observation about MFS that might be applicable. :... :It sounds like it will be great. : :-Alfred Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message