qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] add MADV_DONTFORK to guest physical memory


From: Andrea Arcangeli
Subject: Re: [Qemu-devel] [PATCH] add MADV_DONTFORK to guest physical memory
Date: Thu, 6 Jan 2011 18:49:25 +0100

On Wed, Jan 05, 2011 at 03:27:37PM -0600, Michael Roth wrote:
> On 01/05/2011 02:35 PM, Andrea Arcangeli wrote:
> > On Wed, Jan 05, 2011 at 02:26:19PM -0600, Michael Roth wrote:
> >> Yah you're right, but I've seen several discussions about using mempath
> >> for tmpfs/ram-backed files for things like numa/zram/etc so tend to
> >> think of it as something potentially more than just a hook for
> >> hugetlbfs, which is becoming less and less useful. But the MADV_DONTFORK
> >> stuff should still be immediately applicable.
> >
> > Yes, MADV_DONTFORK should be set all on all guest physical memory
> > without options so I hope the new patch I just posted is fine to stop
> > the spurious -ENOMEM failures in fork.
> 
> The patch in this thread? A couple paths still aren't covered when using 
> -mem-path. Something like this should get them all:

Well the reason of MADV_DONTFORK is to avoid accounting issues with
anonymous memory, mem-path don't have that issue as hugetlbfs skips
the accounting (it has to because hugetlbfs are not always taken from
the regular page allocator). It could be however considered a minor
performance optimization.

Now you mention that you want to use -mem-path for other things too,
so maybe that's why you need it there too. BTW, if you ever need it
for more than hugetlbfs, I'm afraid this MAP_PRIVATE I see when
mem_prealloc isn't set, is going to screw any other potential useful
usage besides hugetlbfs, not exactly sure why it makes any sense to
use MAP_PRIVATE there and not only MAP_SHARED.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]