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
Ingo Molnar writes:
> * Jiri Olsa wrote:
>
>> On Fri, Oct 03, 2014 at 06:34:21AM +0200, Ingo Molnar wrote:
>> >
>> > * Alexander Yarygin wrote:
>> >
[..]
>> >
>> > What's the performance effect of this - i.e. by how much does CPU
>> > use increase due to copying the events?
>> >
>> > Would
* Jiri Olsa wrote:
> On Fri, Oct 03, 2014 at 06:34:21AM +0200, Ingo Molnar wrote:
> >
> > * Alexander Yarygin 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
On Thu, Oct 02, 2014 at 08:38:55PM +0400, Alexander Yarygin 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 po
On Fri, Oct 03, 2014 at 06:34:21AM +0200, Ingo Molnar wrote:
>
> * Alexander Yarygin 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
> > a
* Alexander Yarygin 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 the event is
> actually pro
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
On 10/2/14, 4:32 AM, Alexander Yarygin wrote:
From: David Ahern
At this point the patch is no longer from me. You have done the
migration to ordered_events. You can change that to based on a patch
from ...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
On Thu, Oct 02, 2014 at 07:21:58PM +0400, Alexander Yarygin wrote:
> Jiri Olsa writes:
>
> [..]
>
> >
> > looks ok.. but I was wondering if we could move those repeating
> > bits in function.. something like below (untested, just compiled)
> >
> > thanks,
> > jirka
> >
> >
>
> [..]
>
> Yep, it
Jiri Olsa writes:
[..]
>
> looks ok.. but I was wondering if we could move those repeating
> bits in function.. something like below (untested, just compiled)
>
> thanks,
> jirka
>
>
[..]
Yep, it's better. Just checked - it works. How should we process?
Thanks.
--
To unsubscribe from this li
On Thu, Oct 02, 2014 at 02:32:08PM +0400, Alexander Yarygin wrote:
SNIP
> + if (!oe->buffer) {
> + if (oe->copy_on_queue) {
> + oe->cur_alloc_size -= new_event->header.size;
> + free(new_event);
> +
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
12 matches
Mail list logo
