From: David Chinner Subject: Re: Interaction between Xen and XFS: stray RW mappings Date: Mon, 15 Oct 2007 14:11:33 +1000 Message-ID: <20071015041133.GH995458@sgi.com> References: <470FA7C3.90404@goop.org> <200710151415.07248.nickpiggin@yahoo.com.au> <4712BB05.1020701@goop.org> <200710151726.08387.nickpiggin@yahoo.com.au> <4712E1AA.501@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <4712E1AA.501@goop.org> Sender: linux-kernel-owner@vger.kernel.org To: Jeremy Fitzhardinge Cc: Nick Piggin , David Chinner , xfs@oss.sgi.com, Xen-devel , Linux Kernel Mailing List , Mark Williamson , Morten =?iso-8859-1?Q?B=F8geskov?= , xfs-masters@oss.sgi.com List-Id: xen-devel@lists.xenproject.org On Sun, Oct 14, 2007 at 08:42:34PM -0700, Jeremy Fitzhardinge wrote: > Nick Piggin wrote: > > That's not going to > > happen for at least a cycle or two though, so in the meantime maybe > > an ifdef for that XFS vmap batching code would help? > > > > For now I've proposed a patch to simply eagerly vunmap everything when > CONFIG_XEN is set. It certainly works, but I don't have a good feel for > how much of a performance hit that imposes on XFS. With defaults - little effect as vmap should never be used. It's only when you start using larger block sizes for metadata that this becomes an issue. The CONFIG_XEN workaround should be fine until we get a proper vmap cache.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group