From: Hugh Dickins <hugh.dickins@tiscali.co.uk>
To: William R Speirs <bill.speirs@gmail.com>
Cc: Nick Piggin <npiggin@suse.de>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: vma_merge issue
Date: Thu, 13 Aug 2009 18:33:06 +0100 (BST) [thread overview]
Message-ID: <Pine.LNX.4.64.0908131820500.13350@sister.anvils> (raw)
In-Reply-To: <4A83694F.6090809@gmail.com>
On Wed, 12 Aug 2009, William R Speirs wrote:
> Hugh Dickins wrote:
> >
> > MADV_DONTNEED: brilliant idea, what a shame it doesn't work for you.
> > I'd been on the point of volunteering a bugfix to it to do what you
> > want, it would make sense; but there's a big but... we have sold
> > MADV_DONTNEED as an madvise that only needs non-exclusive access
> > to the mmap_sem, which means it can be used concurrently with faulting,
> > which has made it much more useful to glibc (I believe). If we were
> > to fiddle with vmas and accounting and merging in there, it would go
> > back to needing exclusive mmap_sem, which would hurt important users.
>
> For my own edification, hurt these users how? Performance? Serializing access
> during a MADV_DONTNEED? I wonder how big the "hurt" would be?
Performance, yes: serializing, yes.
I forget the details, others will have paid closer attention, I may
be making this up! But it was something like garbage collection when
when freeing mallocs: it pays off if faults elsewhere in the address
space can occur concurrently, but bad news if exclusive mmap_sem
locks out those faults. Big enough hurt to show up very badly in
some reallife multithreaded apps, and benchmarks hitting the issue.
> > A "refinement" to that suggestion is to put the file on tmpfs:
> > you will then get charged for RAM+swap as you use it, but you can
> > use madvise MADV_REMOVE to unmap pages, punching holes in the file,
> > freeing up those charges. A little baroque, but I think it does
> > amount to a way of doing exactly what you wanted in the first place.
>
> I like this (the refined) idea a lot. I coded it up and works as expected,
> and the way I initially want.
>
> Thanks for taking the time and providing the solution... I appreciate it.
I'm very glad to hear that worked out: thanks for reporting back.
Hugh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2009-08-13 17:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <a1b36c3a0908101347t796dedbat2ecb0535c32f325b@mail.gmail.com>
2009-08-12 18:26 ` Hugh Dickins
2009-08-12 19:04 ` Bill Speirs
2009-08-12 20:23 ` Hugh Dickins
2009-08-12 20:53 ` Hugh Dickins
2009-08-13 1:15 ` William R Speirs
2009-08-13 17:33 ` Hugh Dickins [this message]
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=Pine.LNX.4.64.0908131820500.13350@sister.anvils \
--to=hugh.dickins@tiscali.co.uk \
--cc=bill.speirs@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@suse.de \
/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