From: Jiri Olsa
Date: Wed, 24 Oct 2018 13:34:16 +0200
> On Tue, Oct 23, 2018 at 11:15:03AM -0700, David Miller wrote:
>> From: Arnaldo Carvalho de Melo
>> Date: Tue, 23 Oct 2018 15:05:03 -0300
>>
>> > IIRC this was first done for 'perf record', where we have to stash those
>> > events in the pe
On Tue, Oct 23, 2018 at 11:15:03AM -0700, David Miller wrote:
> From: Arnaldo Carvalho de Melo
> Date: Tue, 23 Oct 2018 15:05:03 -0300
>
> > IIRC this was first done for 'perf record', where we have to stash those
> > events in the perf.data file, to then, later, 'perf report' to process
> > thos
Em Tue, Oct 23, 2018 at 11:15:03AM -0700, David Miller escreveu:
> From: Arnaldo Carvalho de Melo
> Date: Tue, 23 Oct 2018 15:05:03 -0300
> > IIRC this was first done for 'perf record', where we have to stash those
> > events in the perf.data file, to then, later, 'perf report' to process
> > thos
From: Arnaldo Carvalho de Melo
Date: Tue, 23 Oct 2018 15:05:03 -0300
> IIRC this was first done for 'perf record', where we have to stash those
> events in the perf.data file, to then, later, 'perf report' to process
> those, so when working on 'perf top', it just reuses that machinery.
>
> Sure
Em Tue, Oct 23, 2018 at 10:54:05AM -0700, David Miller escreveu:
> From: Jiri Olsa
> Date: Tue, 23 Oct 2018 08:34:52 +0200
>
> > I'm not sure about using the misc field bit defined/used by userland,
> > in case there's some new one comming in future for fork event..
> >
> > but the only other wa
From: Jiri Olsa
Date: Tue, 23 Oct 2018 08:34:52 +0200
> I'm not sure about using the misc field bit defined/used by userland,
> in case there's some new one comming in future for fork event..
>
> but the only other way I can think of now is adding new 'user' event
> for that, but that ended up a
On Mon, Oct 22, 2018 at 10:58:42AM -0700, David Miller wrote:
> From: Jiri Olsa
> Date: Mon, 22 Oct 2018 18:16:13 +0200
>
> > I think the fix might actualy speed things up,
> > but yes, there could be other report regressions
>
> I was about to say the same thing, it could actually speed things
From: Jiri Olsa
Date: Mon, 22 Oct 2018 18:16:13 +0200
> I think the fix might actualy speed things up,
> but yes, there could be other report regressions
I was about to say the same thing, it could actually speed things up.
In the best case, less work is done (clone avoided, and overlapping
maps
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
> > > Date: Fri, 19 Oct 2018 21:05:49 -0700 (PDT)
> > >
> > >
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
> > Date: Fri, 19 Oct 2018 21:05:49 -0700 (PDT)
> >
> > > One solution I've come up with is:
> > >
> > > 1) When synthesizing a fo
(adding Jiri)
On Fri, Oct 19, 2018 at 09:44:01PM -0700, David Miller wrote:
> From: David Miller
> 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) U
From: David Miller
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 hi
12 matches
Mail list logo
