mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: "David Chinner" <dgc@sgi.com>,
	xfs@oss.sgi.com, Xen-devel <xen-devel@lists.xensource.com>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Mark Williamson" <mark.williamson@cl.cam.ac.uk>,
	"Morten Bøgeskov" <xen-users@morten.bogeskov.dk>,
	xfs-masters@oss.sgi.com
Subject: Re: Interaction between Xen and XFS: stray RW mappings
Date: Mon, 15 Oct 2007 14:15:06 +1000	[thread overview]
Message-ID: <200710151415.07248.nickpiggin@yahoo.com.au> (raw)
In-Reply-To: <4712A254.4090604@goop.org>

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?

  parent reply	other threads:[~2007-10-14 23:24 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-12 16:58 Jeremy Fitzhardinge
2007-10-12 17:08 ` Jeremy Fitzhardinge
2007-10-14 22:56 ` David Chinner
2007-10-14 23:12   ` Jeremy Fitzhardinge
2007-10-14 23:33     ` David Chinner
2007-10-15  4:15     ` Nick Piggin [this message]
2007-10-15  0:57       ` Jeremy Fitzhardinge
2007-10-15  7:26         ` Nick Piggin
2007-10-15  3:42           ` Jeremy Fitzhardinge
2007-10-15  4:11             ` David Chinner
2007-10-15  4:18               ` Jeremy Fitzhardinge
2007-10-15  4:25                 ` David Chinner
2007-10-15  8:31                   ` [xfs-masters] " Christoph Hellwig
2007-10-22  3:18       ` dean gaudet
2007-10-22  3:34         ` Jeremy Fitzhardinge
2007-10-22  4:28           ` dean gaudet
2007-10-22  4:39             ` Nick Piggin
2007-10-22 18:37               ` Jeremy Fitzhardinge
2007-10-22 18:32             ` Jeremy Fitzhardinge
2007-10-22 13:47           ` Andi Kleen
2007-10-22 18:40             ` Jeremy Fitzhardinge
2007-10-22 19:07               ` Andi Kleen
2007-10-22 19:11                 ` Jeremy Fitzhardinge
2007-10-22 22:32                 ` David Chinner
2007-10-22 23:35                   ` Andi Kleen
2007-10-23  0:16                     ` Zachary Amsden
2007-10-23  0:36                     ` David Chinner
2007-10-23  7:04                       ` [patch] " David Chinner
2007-10-23  9:30                         ` Andi Kleen
2007-10-23 12:41                           ` David Chinner
2007-10-23 14:33                             ` Jeremy Fitzhardinge
2007-10-24  4:36                           ` [PATCH] Allow lazy unmapping by taking extra page references V2 David Chinner
2007-10-24  5:08                             ` Jeremy Fitzhardinge
2007-10-24 21:48                               ` [PATCH] Allow lazy unmapping by taking extra page references V3 David Chinner
2007-10-24 22:46                                 ` Jeremy Fitzhardinge
2007-10-24 23:21                                   ` David Chinner
2007-10-23  9:28                       ` Interaction between Xen and XFS: stray RW mappings Andi Kleen
2007-10-15  9:36   ` Andi Kleen
2007-10-15 14:56     ` Nick Piggin
2007-10-15 11:07       ` Andi Kleen
2007-10-15 11:28         ` Nick Piggin
2007-10-15 12:54           ` Andi Kleen
2007-10-21 12:17             ` Dave Airlie
2007-10-21 22:16         ` Benjamin Herrenschmidt
2007-10-22  9:49           ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200710151415.07248.nickpiggin@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=dgc@sgi.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.williamson@cl.cam.ac.uk \
    --cc=xen-devel@lists.xensource.com \
    --cc=xen-users@morten.bogeskov.dk \
    --cc=xfs-masters@oss.sgi.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®