[Top] [All Lists]

[xfs-masters] Re: Interaction between Xen and XFS: stray RW mappings

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [xfs-masters] Re: Interaction between Xen and XFS: stray RW mappings
From: David Chinner <dgc@xxxxxxx>
Date: Mon, 15 Oct 2007 14:11:33 +1000
Cc: Nick Piggin <nickpiggin@xxxxxxxxxxxx>, David Chinner <dgc@xxxxxxx>, xfs@xxxxxxxxxxx, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Mark Williamson <mark.williamson@xxxxxxxxxxxx>, Morten Bøgeskov <xen-users@xxxxxxxxxxxxxxxxxx>, xfs-masters@xxxxxxxxxxx
In-reply-to: <4712E1AA.501@xxxxxxxx>
References: <470FA7C3.90404@xxxxxxxx> <200710151415.07248.nickpiggin@xxxxxxxxxxxx> <4712BB05.1020701@xxxxxxxx> <200710151726.08387.nickpiggin@xxxxxxxxxxxx> <4712E1AA.501@xxxxxxxx>
Reply-to: xfs-masters@xxxxxxxxxxx
Sender: xfs-masters-bounce@xxxxxxxxxxx
User-agent: Mutt/
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....


Dave Chinner
Principal Engineer
SGI Australian Software Group

<Prev in Thread] Current Thread [Next in Thread>