On 10/24/13 8:07 AM, Arnaldo Melo wrote:
What I thought was since we have to allocate memory _somewhere_ we could
size the ring buffer in such a way that it would be big enough for us to
leave those referenced entries there, not consumed, till we actually
consume them when reordering the events,
Em Thu, Oct 24, 2013 at 02:12:29PM +0100, David Ahern escreveu:
> On 10/24/13 1:27 PM, Arnaldo Melo wrote:
> The driving use case is my perf-daemon:
> https://github.com/dsahern/linux/blob/perf-sched-timehist-3.11/tools/perf/schedmon.c,
> line 271.
>
> Rather than have the perf infrastructure man
On 10/24/13 1:27 PM, Arnaldo Melo wrote:
Em Thu, Oct 24, 2013 at 11:23:32AM +0100, David Ahern escreveu:
On 10/24/13 10:30 AM, Frederic Weisbecker wrote:
Bah, checking that again, there don't seem to be a bug there. Actually
the sample buffer is reset after we pick the last entry. So it looks
a
Em Thu, Oct 24, 2013 at 11:23:32AM +0100, David Ahern escreveu:
> On 10/24/13 10:30 AM, Frederic Weisbecker wrote:
> >Bah, checking that again, there don't seem to be a bug there. Actually
> >the sample buffer is reset after we pick the last entry. So it looks
> >all fine. I got confused as usual.
On 10/24/13 10:30 AM, Frederic Weisbecker wrote:
Bah, checking that again, there don't seem to be a bug there. Actually
the sample buffer is reset after we pick the last entry. So it looks
all fine. I got confused as usual. Nevermind.
Ok. I had not come back to this thread since I decided on a
2013/9/14 Frederic Weisbecker :
> On Fri, Sep 06, 2013 at 01:37:01PM -0600, David Ahern wrote:
>> 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 u
On 10/2/13 6:38 AM, Jiri Olsa wrote:
Examples hitting this problem are 'perf kvm stat live', especially with nested
VMs which generate 100,000+ traces per second, and a command processing
scheduling events with a high rate of context switching -- e.g., running
'perf bench sched pipe'.
This patch
On Wed, Oct 02, 2013 at 02:18:21PM +0200, Jiri Olsa wrote:
> On Fri, Sep 06, 2013 at 01:37:01PM -0600, David Ahern wrote:
> > 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
> >
On Fri, Sep 06, 2013 at 01:37:01PM -0600, David Ahern wrote:
> 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 th
On 9/16/13 10:40 AM, Frederic Weisbecker wrote:
Yes. I could make it the default behavior; just overhead in doing
that (malloc/copy for each event).
Are there any tool that don't suffer from this bug somehow? If not then it must
be applied unconditionally.
I believe only 'live' commands would
On Sat, Sep 14, 2013 at 11:25:40AM -0600, David Ahern wrote:
> On 9/14/13 10:16 AM, Frederic Weisbecker wrote:
> >>@@ -676,7 +682,12 @@ int perf_session_queue_event(struct perf_session *s,
> >>union perf_event *event,
> >>
> >>new->timestamp = timestamp;
> >>new->file_offset = file_offset;
On 9/14/13 10:16 AM, Frederic Weisbecker wrote:
@@ -676,7 +682,12 @@ int perf_session_queue_event(struct perf_session *s, union
perf_event *event,
new->timestamp = timestamp;
new->file_offset = file_offset;
- new->event = event;
+
+ if (s->copy_on_queue) {
+
On Fri, Sep 06, 2013 at 01:37:01PM -0600, David Ahern wrote:
> 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 th
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 events live (ie., re
14 matches
Mail list logo
