From owner-freebsd-hackers Sun Jun 13 7:25:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (Postfix) with SMTP id 502F914D22 for ; Sun, 13 Jun 1999 07:25:46 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (qmail 8173 invoked from network); 13 Jun 1999 14:25:44 -0000 Received: from dyson.iquest.net (198.70.144.127) by iquest3.iquest.net with SMTP; 13 Jun 1999 14:25:44 -0000 Received: (from root@localhost) by dyson.iquest.net (8.9.1/8.9.1) id JAA06530; Sun, 13 Jun 1999 09:25:38 -0500 (EST) From: "John S. Dyson" Message-Id: <199906131425.JAA06530@dyson.iquest.net> Subject: Re: problem for the VM gurus In-Reply-To: <199906130439.VAA65304@apollo.backplane.com> from Matthew Dillon at "Jun 12, 99 09:39:25 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Sun, 13 Jun 1999 09:25:38 -0500 (EST) Cc: hgoldste@bbs.mpcs.com, dyson@iquest.net, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > * We hack a fix to deal with the mmap/write case. > > A permanent vnode locking fix is many months away because core > decided to ask Kirk to fix it, which was news to me at the time. > However, I agree with the idea of having Kirk fix VNode locking. > > But since this sort of permanent fix is months away, we really need > an interim solution to the mmap/write deadlock case. > > The easiest interim solution is to break write atomicy. That is, > unlock the vnode if the backing store of the uio being written is > (A) vnode-pager-backed and (B) not all in-core. > > This will generally fix all known deadlock situations but at the > cost of write atomicy in certain cases. We can use the same hack > that pipe code uses and only guarentee write atomicy for small > block sizes. We would do this by wiring ( and faulting, if > necessary ) the first N pages of the uio prior to locking the vnode. > > We cannot wire all the pages of the uio since the user may specify > a very large buffer - megabytes or gigabytes. > > * Stage 3: Permanent fix is committed by generally fixing vnode locks > and VFS layering. > > ... which may be 6 months if Kirk agrees to do a complete rewrite > of the vnode locking algorithms. > Regarding atomicy: Remember that you cannot assume that the mappings stay the same during almost any I/O mechanism anymore. The issue of wiring pages and assuming constant mapping has to be resolved. A careful definition of whether or not one is doing I/O to an address or I/O to a specific piece of memory. I know that this is an end condition, but it has consequences as to the effects on the design. (I suspect that a punt to do I/O to a virtual address is correct, but those change, and also disappear.) John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message