From: Jeremy Fitzhardinge Subject: Re: Interaction between Xen and XFS: stray RW mappings Date: Sun, 14 Oct 2007 16:12:20 -0700 Message-ID: <4712A254.4090604@goop.org> References: <470FA7C3.90404@goop.org> <20071014225618.GN23367404@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20071014225618.GN23367404@sgi.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: David Chinner Cc: nickpiggin@yahoo.com.au, Xen-devel , =?ISO-8859-1?Q?Morten_?=, Linux Kernel Mailing List , =?ISO-8859-1?Q?B=F8geskov?= , xfs@oss.sgi.com, xfs-masters@oss.sgi.com, Mark Williamson List-Id: xen-devel@lists.xenproject.org David Chinner wrote: > You mean xfs_buf.c. > Yes, sorry. > And yes, we delay unmapping pages until we have a batch of them > to unmap. vmap and vunmap do not scale, so this is batching helps > alleviate some of the worst of the problems. > How much performance does it cost? What kind of workloads would it show up under? > Realistically, if this delayed release of vmaps is a problem for > Xen, then I think that some generic VM solution is needed to this > problem as vmap() is likely to become more common in future (think > large blocks in filesystems). Nick - any comments? > Well, the only real problem is that the pages are returned to the free pool and reallocated while still being part of a mapping. If the pages are still owned by the filesystem/pagecache, then there's no problem. What's the lifetime of things being vmapped/unmapped in xfs? Are they necessarily being freed when they're unmapped, or could unmapping of freed memory be more immediate than other memory? Maybe it just needs a notifier chain or something. J