----- On Jun 26, 2020, at 9:58 AM, rostedt rost...@goodmis.org wrote:
> On Thu, 25 Jun 2020 23:35:52 -0400
> Steven Rostedt <rost...@goodmis.org> wrote:
>
>> I have to think about this more, as I think there's a flaw in this
>> cmpxchg algorithm.
>
> Bah, that was all wrong. I need to incorporate the seq counter into the
> time stamp. Luckily I only use 59 bits for a full time stamp (gives me
> 18 years of nanoseconds), which gives me 5 bits to pay with, and all I
> need is 4 (2 for top and 2 for bottom). Now I can make the timestamp 60
> bits with 30 bits from the top and 30 from the bottom, and using two
> bits in each of those as a sequence counter.
>
> If after reading top and bottom, if the seq bits match, then the two
> match and can be put together as a valid number. Now I have this:
[...]
>
> static inline bool __rb_time_read(rb_time_t *t, u64 *ret, unsigned long *cnt)
> {
> unsigned long top, bottom;
>
> top = local_read(&t->top);
> bottom = local_read(&t->bottom);
>
> *cnt = rb_time_cnt(top);
>
> if (*cnt != rb_time_cnt(bottom))
> return false;
>
> *ret = rb_time_val(top, bottom);
> return true;
> }
If __rb_time_read or rb_time_cmpxchg are used in an interrupt over
rb_time_set (between setting top and bottom), those will never succeed.
How is this case handled ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
