Re: [PATCH 2/2] More precise timestamps for nested writes

[Suresh E. Warrier]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/