From: Don Zickus <dzickus@redhat.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: David Miller <davem@davemloft.net>,
acme@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: perf overlapping maps...
Date: Mon, 22 Oct 2018 13:10:00 -0400 [thread overview]
Message-ID: <20181022171000.67rndl6br4fot7dm@redhat.com> (raw)
In-Reply-To: <20181022161613.GF2945@krava>
On Mon, Oct 22, 2018 at 06:16:13PM +0200, Jiri Olsa wrote:
> On Mon, Oct 22, 2018 at 10:07:38AM -0400, Don Zickus wrote:
> > (adding Jiri)
> >
> > On Fri, Oct 19, 2018 at 09:44:01PM -0700, David Miller wrote:
> > > From: David Miller <davem@davemloft.net>
> > > Date: Fri, 19 Oct 2018 21:05:49 -0700 (PDT)
> > >
> > > > One solution I've come up with is:
> > > >
> > > > 1) When synthesizing a fork event, set PERF_RECORD_MISC_COMM_EXEC in
> > > > header->misc.
> > > >
> > > > 2) Use this to elide the map groups clone in
> > > > thread__clone_map_groups().
> > >
> > > Looking into code history, I notice:
> > >
> > > commit 363b785f3805a2632eb09a8b430842461c21a640
> > > Author: Don Zickus <dzickus@redhat.com>
> > > Date: Fri Mar 14 10:43:44 2014 -0400
> > >
> > > perf tools: Speed up thread map generation
> > >
> > > and the subsequent:
> > >
> > > commit 4aa5f4f7bb8bc41cba15bcd0d80c4fb085027d6b
> > > Author: Arnaldo Carvalho de Melo <acme@redhat.com>
> > > Date: Fri Feb 27 19:52:10 2015 -0300
> > >
> > > perf tools: Fix FORK after COMM when synthesizing records for pre-existing threads
> > >
> > > If Don wanted to have the map cloning to happen for processes without
> > > CLONE_VM, I'm not sure that's right.
> > >
> > > For real threads, we just take a reference to the map group from
> > > the parent.
> > >
> > > Don, a quick summary. If we synthesize a fork event, let's say for an
> > > emacs process. perf will clone the map groups of the parent bash
> > > shell which invoked emacs. Via:
> > >
> > > thread__fork(thread, parent, timestamp)
> > > {
> > > ...
> > > thread__clone_map_groups(thread, parent)
> > > {
> > > ...
> > > map_groups__clone(thread, parent->mg)
> > >
> > > Which is completely bogus. It brings all of the bash process maps
> > > into the emacs thread map group. Then we process the emacs mmap2
> > > events, which overlap the bash process maps already cloned into the
> > > emacs map group. And this make all kinds of erroneous things happen.
> > >
> > > I'm suggesting to elide the map groups clone in this situation where
> > > we are synthesizing the fork.
>
> right, this seems correct.. we should only clone parent maps
> for kernel fork event, not when we synthesize.. I'll check
> the solution you proposed and try to come with a patch
Thanks Jiri for helping me out on this!
Cheers,
Don
>
> >
> > Hi David,
> >
> > Honestly, I remember very little of this change other than we ran specjbb
> > which created thousands of threads and we wanted a better way to handle that
> > situation (waiting 15 minutes seemed wrong).
> >
> > Jiri Olsa is probably more knowledgable about this then I am these days and
> > can work with Joe to re-do the test to verify any suggested changes does not
> > break our intended use case.
> >
> > Thinking about it more, I am wondering if we did this because we ran the
> > test and it takes about 20 minutes to 'warm up' then we attached perf to the
> > test. This implies we had to handle the situation where 10K threads already
> > existed hence our optimization. But I can be wrong.
> >
> > Your suggestion is probably right and I am sure we can reproduce the
> > scenario to verify things didn't regress.
>
> I think the fix might actualy speed things up,
> but yes, there could be other report regressions
>
> thanks,
> jirka
next prev parent reply other threads:[~2018-10-22 17:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-20 4:05 perf overlapping maps David Miller
2018-10-20 4:44 ` David Miller
2018-10-22 14:07 ` Don Zickus
2018-10-22 16:16 ` Jiri Olsa
2018-10-22 17:10 ` Don Zickus [this message]
2018-10-22 17:58 ` David Miller
2018-10-23 6:34 ` Jiri Olsa
2018-10-23 17:54 ` David Miller
2018-10-23 18:05 ` Arnaldo Carvalho de Melo
2018-10-23 18:15 ` David Miller
2018-10-23 19:27 ` Arnaldo Carvalho de Melo
2018-10-24 11:34 ` Jiri Olsa
2018-10-24 21:30 ` David Miller
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=20181022171000.67rndl6br4fot7dm@redhat.com \
--to=dzickus@redhat.com \
--cc=acme@kernel.org \
--cc=davem@davemloft.net \
--cc=jolsa@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).