From owner-freebsd-current Mon Jun 28 23:54: 5 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 67F3714C87 for ; Mon, 28 Jun 1999 23:54:04 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id XAA26968; Mon, 28 Jun 1999 23:53:40 -0700 (PDT) (envelope-from dillon) Date: Mon, 28 Jun 1999 23:53:40 -0700 (PDT) From: Matthew Dillon Message-Id: <199906290653.XAA26968@apollo.backplane.com> To: Julian Elischer Cc: Kirk McKusick , Peter Wemm , Alan Cox , Mike Smith , "John S. Dyson" , dg@root.com, dyson@iquest.net, current@FreeBSD.ORG, Greg Lehey Subject: Re: Found the startup panic - ccd ( patch included ) References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :The problem I see with this is teh resource load in times of critical :resource shortage. If you need to suddenly generate a writable page.. :where does the page come from? If resources are not available, I guess you :could just stall the write until the original page is reconstituted (after :soft updates remerges backed out data), but there is the danger that the :write request could be very large, and that duplicated data could be both :very expensive and very "surprising" to the system. : :Still it's an intriguing concept. How much CPU do you "use" to generate :the writable copies before you start going backwards in performance. : :julian This was the first thing I considered. It turns out to be a non-problem because you've already initiated the I/O - if you have a critical resource shortage the blockage occurs in a process context and not an interrupt context, and the you are guarenteed a page will become available 'soon'. Duplicating the data is almost certainly not going to be as expensive as waiting for the I/O to complete would be. And it really doesn't happen all that often since the buffer cache normally operates in an LRU fashion. Where it wins the most is that it allows the filesystem to do write-behind without intefering with performance. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message