On 04/15/2015 04:16 AM, Peter Zijlstra wrote:
> On Mon, Apr 13, 2015 at 09:38:01PM -0500, Suresh E. Warrier wrote:
>
>> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
>> index c9b3005..0a2d862 100644
>> --- a/kernel/trace/ring_buffer.c
>> +++ b/kernel/trace/ring_buffer.c
>> @@ -482,6 +482,7 @@ struct ring_buffer_per_cpu {
>> unsigned long read_bytes;
>> u64 write_stamp;
>> u64 read_stamp;
>> + u64 last_stamp;
>> /* ring buffer pages to update, > 0 to add, < 0 to remove */
>> int nr_pages_to_update;
>> struct list_head new_pages; /* new pages to add */
>
> So what is wrong with something like:
>
> u64 rb_get_delta(struct ring_buffer_per_cpu *cpu_buffer)
> {
> u64 last, now;
>
> for (;;) {
> last = cpu_buffer->last_stamp;
> now = cpu_buffer->buffer->clock();
>
> if (cmpxchg_local(&cpu_buffer->last_stamp, last, now) == last)
> break;
>
> cpu_relax();
> }
>
> return now - last;
> }
>
> Of course, LL/SC on power stinks, but on most archs this is actually
> fairly fast.
>
I am not sure it will help. The delta we assign to the current
event has to be the difference of the "actual" timestamps of the
last event in the buffer and the current event. If we can't be sure
of the delta, we can let it be zero which is the current behavior
for nested writes.
Thus, one way to fix my patch to handle NMIs is to recheck the
last_stamp after the event has been reserved in the buffer. If it
has changed since we computed the delta, we can simply reset the
delta to zero. This should only happen if an NMI occurs within the
short critical section and it also does a trace.
-suresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
