Em Mon, Sep 22, 2014 at 09:04:10AM +0200, Jiri Olsa escreveu:
> On Thu, Sep 18, 2014 at 09:07:38PM +0400, Alexander Yarygin wrote:
> > +++ b/tools/perf/util/session.c
> > @@ -542,7 +542,13 @@ int perf_session_queue_event(struct perf_session *s,
> > union perf_event *event,
> > return
Em Mon, Sep 22, 2014 at 09:04:10AM +0200, Jiri Olsa escreveu:
On Thu, Sep 18, 2014 at 09:07:38PM +0400, Alexander Yarygin wrote:
+++ b/tools/perf/util/session.c
@@ -542,7 +542,13 @@ int perf_session_queue_event(struct perf_session *s,
union perf_event *event,
return -ENOMEM;
On Fri, Sep 19, 2014 at 12:48:21PM +0400, Alexander Yarygin wrote:
> David Ahern writes:
>
> > On 9/18/14, 2:21 PM, David Ahern wrote:
> >> On 9/18/14, 12:53 PM, Arnaldo Carvalho de Melo wrote:
> >>> If nobody objects I'll merge this patch, as it fixes problems, but I
> >>> wonder if the best
On Thu, Sep 18, 2014 at 09:07:38PM +0400, Alexander Yarygin wrote:
> From: David Ahern
>
> When processing events the session code has an ordered samples queue which is
> used to time-sort events coming in across multiple mmaps. At a later point in
> time samples on the queue are flushed up to
On Thu, Sep 18, 2014 at 09:07:38PM +0400, Alexander Yarygin wrote:
From: David Ahern dsah...@gmail.com
When processing events the session code has an ordered samples queue which is
used to time-sort events coming in across multiple mmaps. At a later point in
time samples on the queue are
On Fri, Sep 19, 2014 at 12:48:21PM +0400, Alexander Yarygin wrote:
David Ahern dsah...@gmail.com writes:
On 9/18/14, 2:21 PM, David Ahern wrote:
On 9/18/14, 12:53 PM, Arnaldo Carvalho de Melo wrote:
If nobody objects I'll merge this patch, as it fixes problems, but I
wonder if the best
David Ahern writes:
> On 9/19/14, 2:48 AM, Alexander Yarygin wrote:
>> It did't work. Turned out that there is at least one event alive after
>> finished_round(), usually I get more - ~20. Not sure why, maybe it's
>> another problem which should be solved at first?
>
> hmm
On 9/19/14, 2:48 AM, Alexander Yarygin wrote:
It did't work. Turned out that there is at least one event alive after
finished_round(), usually I get more - ~20. Not sure why, maybe it's
another problem which should be solved at first?
hmm perf_evlist__mmap_consume is not at the event
David Ahern writes:
> On 9/18/14, 2:21 PM, David Ahern wrote:
>> On 9/18/14, 12:53 PM, Arnaldo Carvalho de Melo wrote:
>>> If nobody objects I'll merge this patch, as it fixes problems, but I
>>> wonder if the best wouldn't be simply not calling
>>> perf_evlist__mmap_consume() till the last
David Ahern dsah...@gmail.com writes:
On 9/18/14, 2:21 PM, David Ahern wrote:
On 9/18/14, 12:53 PM, Arnaldo Carvalho de Melo wrote:
If nobody objects I'll merge this patch, as it fixes problems, but I
wonder if the best wouldn't be simply not calling
perf_evlist__mmap_consume() till the last
On 9/19/14, 2:48 AM, Alexander Yarygin wrote:
It did't work. Turned out that there is at least one event alive after
finished_round(), usually I get more - ~20. Not sure why, maybe it's
another problem which should be solved at first?
hmm perf_evlist__mmap_consume is not at the event
David Ahern dsah...@gmail.com writes:
On 9/19/14, 2:48 AM, Alexander Yarygin wrote:
It did't work. Turned out that there is at least one event alive after
finished_round(), usually I get more - ~20. Not sure why, maybe it's
another problem which should be solved at first?
hmm
On 9/18/14, 2:21 PM, David Ahern wrote:
On 9/18/14, 12:53 PM, Arnaldo Carvalho de Melo wrote:
If nobody objects I'll merge this patch, as it fixes problems, but I
wonder if the best wouldn't be simply not calling
perf_evlist__mmap_consume() till the last event there is in fact
consumed... I.e.
On 9/18/14, 12:53 PM, Arnaldo Carvalho de Melo wrote:
If nobody objects I'll merge this patch, as it fixes problems, but I
wonder if the best wouldn't be simply not calling
perf_evlist__mmap_consume() till the last event there is in fact
consumed... I.e. as we _really_ consume the events, we
Em Thu, Sep 18, 2014 at 09:07:38PM +0400, Alexander Yarygin escreveu:
> From: David Ahern
> When processing events the session code has an ordered samples queue which is
> used to time-sort events coming in across multiple mmaps. At a later point in
> time samples on the queue are flushed up to
From: David Ahern
When processing events the session code has an ordered samples queue which is
used to time-sort events coming in across multiple mmaps. At a later point in
time samples on the queue are flushed up to some timestamp at which point the
event is actually processed.
When analyzing
On 9/18/14, 12:53 PM, Arnaldo Carvalho de Melo wrote:
If nobody objects I'll merge this patch, as it fixes problems, but I
wonder if the best wouldn't be simply not calling
perf_evlist__mmap_consume() till the last event there is in fact
consumed... I.e. as we _really_ consume the events, we
On 9/18/14, 2:21 PM, David Ahern wrote:
On 9/18/14, 12:53 PM, Arnaldo Carvalho de Melo wrote:
If nobody objects I'll merge this patch, as it fixes problems, but I
wonder if the best wouldn't be simply not calling
perf_evlist__mmap_consume() till the last event there is in fact
consumed... I.e.
From: David Ahern dsah...@gmail.com
When processing events the session code has an ordered samples queue which is
used to time-sort events coming in across multiple mmaps. At a later point in
time samples on the queue are flushed up to some timestamp at which point the
event is actually
Em Thu, Sep 18, 2014 at 09:07:38PM +0400, Alexander Yarygin escreveu:
From: David Ahern dsah...@gmail.com
When processing events the session code has an ordered samples queue which is
used to time-sort events coming in across multiple mmaps. At a later point in
time samples on the queue are
20 matches
Mail list logo
