All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vassilis Virvilis <v.virvilis@biovista.com>
To: "Bruno Prémont" <bonbons@linux-vserver.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Debugging COW (copy on write) memory after fork: Is it possible to dump only the private anonymous memory of a process?
Date: Mon, 08 Apr 2013 10:41:43 +0300	[thread overview]
Message-ID: <516274B7.4050002@biovista.com> (raw)
In-Reply-To: <20130406201114.6477d1e4@neptune.home>

On 04/06/2013 09:11 PM, Bruno Prémont wrote:
> On Fri, 05 April 2013 Vassilis Virvilis<v.virvilis@biovista.com>  wrote:
>>
>> Question
>> --------
>>
>> Is it possible to dump only the private anonymous memory of a process?
>
> I don't know if that's possible, but from your background you could
> probably work around it be mmap()ing the memory you need and once
> initialized mark all of that memory read-only (if you mmap very large
> chunks you can even benefit from huge-pages).
>
> Any of the forked processes that tried to access the memory would then
> get a signal if they ever tried to write to the data (and thus unsharing it)
>

I can't do that. We are talking about an existing system (in perl with C 
modules) that has been parallelized in a second step.

> If you allocate and initialize all of your memory in little malloc()'ed
> chunks it's possibly glibc's memory housekeeping that unshares all those
> pages over time.

Yes I suppose it is a series of mallocs. I could easily verify that with 
strace. However if glibc's memory housekeeping undermines the COW 
behaviour that would be very bad.

I have unit tests that I was able to work around the usual perl problems 
that cause memory unsharing such as the reference counting and hash 
accessing. Garbage collector shouldn't be a problem because there is 
nothing to collect from the shared memory, only private local variables 
that go out of scope. The problem is when I am employing these 
workarounds in the live system (with considerable IO) I am getting 
massive unsharing. So I thought to have a look and see what's going in 
two or three consecutive private memory dumps.

The point is I need to locate the source of the memory unsharing. Any 
ideas how this can be done?

At this point I could try in house compiled kernels if I can enable some 
logging to track this behavior. Does any knob like this exist? Even as 
an #ifdef?

	Vassilis

      reply	other threads:[~2013-04-08  7:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-05  9:53 Debugging COW (copy on write) memory after fork: Is it possible to dump only the private anonymous memory of a process? Vassilis Virvilis
2013-04-06 18:11 ` Bruno Prémont
2013-04-08  7:41   ` Vassilis Virvilis [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=516274B7.4050002@biovista.com \
    --to=v.virvilis@biovista.com \
    --cc=bonbons@linux-vserver.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.