From: Jiri Olsa <jolsa@redhat.com>
To: Andi Kleen <ak@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Michael Petlan <mpetlan@redhat.com>
Subject: Re: [PATCH 3/3] perf tools: Make 'struct map_shared' truly shared
Date: Mon, 14 Oct 2019 10:48:11 +0200 [thread overview]
Message-ID: <20191014084811.GA9700@krava> (raw)
In-Reply-To: <20191014031054.GJ9933@tassilo.jf.intel.com>
On Sun, Oct 13, 2019 at 08:10:54PM -0700, Andi Kleen wrote:
> On Sun, Oct 13, 2019 at 05:14:27PM +0200, Jiri Olsa wrote:
> > Andi reported that maps cloning is eating lot of memory and
> > it's probably unnecessary, because they keep the same data.
> >
> > Changing 'struct map_shared' to be a pointer inside 'struct map',
> > so it can be shared on fork. Changing the map__clone function to
> > actually share 'struct map_shared' for cloned maps.
> >
> > The 'struct map_shared' carries its own refcnt counter, which is
> > incremented when it's assigned to new 'struct map' and decremented
> > when 'struct map' gets deleted in map__delete (its refcnt is 0).
> >
> > This 'maps sharing' seems to save lot of heap for reports with
> > many forks/cloned mmaps (over 60% in example below).
>
> The one case I wasn't sure about is with JIT support. So if
> a map gets modified with fixup/start from /tmp/perf-%d
> in one process, would it impact the other too?
there are cases we do the fixup for maps and we clone
the map fully in those cases, but not sure now what JIT
does.. I'll check the JIT path
thanks,
jirka
>
> We may need a COW operation for this (hopefully rare) case.
>
> -Andi
next prev parent reply other threads:[~2019-10-14 8:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-13 15:14 [PATCH 0/3] perf tools: Share struct map after clone Jiri Olsa
2019-10-13 15:14 ` [PATCH 1/3] perf tools: Allow to build with -ltcmalloc Jiri Olsa
2019-10-14 1:33 ` Andi Kleen
2019-10-14 14:01 ` Arnaldo Carvalho de Melo
2019-10-21 23:19 ` [tip: perf/core] " tip-bot2 for Jiri Olsa
2019-10-13 15:14 ` [PATCH 2/3] perf tools: Separate shareable part of 'struct map' into 'struct map_shared' Jiri Olsa
2019-10-13 15:14 ` [PATCH 3/3] perf tools: Make 'struct map_shared' truly shared Jiri Olsa
2019-10-14 3:10 ` Andi Kleen
2019-10-14 8:48 ` Jiri Olsa [this message]
2019-10-14 19:20 ` Jiri Olsa
2019-10-14 19:46 ` Andi Kleen
2019-10-14 20:40 ` Jiri Olsa
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=20191014084811.GA9700@krava \
--to=jolsa@redhat.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mpetlan@redhat.com \
--cc=namhyung@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox