| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: Interaction between Xen and XFS: stray RW mappings
|
To: |
Jeremy Fitzhardinge <jeremy@xxxxxxxx> |
|
Subject: |
[Xen-devel] Re: Interaction between Xen and XFS: stray RW mappings |
|
From: |
Nick Piggin <nickpiggin@xxxxxxxxxxxx> |
|
Date: |
Mon, 15 Oct 2007 14:15:06 +1000 |
|
Cc: |
Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, David Chinner <dgc@xxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Morten Bøgeskov <xen-users@xxxxxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, xfs-masters@xxxxxxxxxxx, Mark Williamson <mark.williamson@xxxxxxxxxxxx> |
|
Delivery-date: |
Mon, 15 Oct 2007 03:58:50 -0700 |
|
Domainkey-signature: |
a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=Received:X-YMail-OSG:From:To:Subject:Date:User-Agent:Cc:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id; b=ZdFG2HgYloG6/acEhW+YbfV5911A/JXY4PlQ+eetr4LG+FhGpUn0dP5aBs86eYMbEUzqMtANGMMdF12V8s727fRi197B8ODOvzzLsvHfb1QDVM6Oas+AuGysnAoQUKyXSRIBCKv6E9gUhuAy2xy94qw++GTgdPoRi7R+J2WMjaM= ; |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<4712A254.4090604@xxxxxxxx> |
|
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
|
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
|
List-post: |
<mailto:xen-devel@lists.xensource.com> |
|
List-subscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
|
List-unsubscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
|
References: |
<470FA7C3.90404@xxxxxxxx> <20071014225618.GN23367404@xxxxxxx> <4712A254.4090604@xxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
User-agent: |
KMail/1.9.5 |
On Monday 15 October 2007 09:12, Jeremy Fitzhardinge wrote:
> 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?
Yes, as Dave said, vmap (more specifically: vunmap) is very expensive
because it generally has to invalidate TLBs on all CPUs.
I'm looking at some more general solutions to this (already have some
batching / lazy unmapping that replaces the XFS specific one), however
they are still likely going to leave vmap mappings around after freeing
the page.
We _could_ hold on to the pages as well, but that's pretty inefficient.
The memory cost of keeping the mappings around tends to be well under
1% the cost of the page itself. OTOH we could also avoid lazy flushes
on architectures where it is not costly. Either way, it probably would
require an arch hook or even a couple of ifdefs in mm/vmalloc.c for
Xen. Although... it would be nice if Xen could take advantage of some
of these optimisations as well.
What's the actual problem for Xen? Anything that can be changed?
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home