Date: Sun, 13 Jun 1999 09:25:38 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: hgoldste@bbs.mpcs.com, dyson@iquest.net, freebsd-hackers@FreeBSD.ORG Subject: Re: problem for the VM gurus Message-ID: <199906131425.JAA06530@dyson.iquest.net> In-Reply-To: <199906130439.VAA65304@apollo.backplane.com> from Matthew Dillon at "Jun 12, 99 09:39:25 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > * 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906131425.JAA06530>