On 08/15, Frederic Weisbecker wrote: > > 2014-08-14 16:39 GMT+02:00 Oleg Nesterov <o...@redhat.com>: > > On 08/14, Frederic Weisbecker wrote: > >> > >> I mean the read side doesn't use a lock with seqlocks. It's only made > >> of barriers and sequence numbers to ensure the reader doesn't read > >> some half-complete update. But other than that it can as well see the > >> update n - 1 since barriers don't enforce latest results. > > > > Yes, sure, read_seqcount_begin/read_seqcount_retry "right after" > > write_seqcount_begin-update-write_seqcount_begin can miss "update" part > > along with ->sequence modifications. > > > > But I still can't understand how this can lead to non-monotonic results, > > could you spell? > > Well lets say clock = T. > CPU 0 updates at T + 1. > Then I call clock_gettime() from CPU 1 and CPU 2. CPU 1 reads T + 1 > while CPU 1 still reads T. > If I do yet another round of clock_gettime() on CPU 1 and CPU 2, it's > possible that CPU 2 still sees T. With the spinlocked version that > thing can't happen, the second round would read at least T + 1 for > both CPUs.
But this is fine? And CPU 2 doesn't see a non-monotonic result? OK, this could be wrong if, say, void print_clock(void) { lock(SOME_LOCK); printk(..., clock_gettime()); unlock(SOME_LOCK); } printed the non-monotonic numbers if print_clock() is called on CPU_1 and then on CPU_2. But in this case CPU_2 can't miss the changes on CPU_0 if they were already visible to CPU_1 under the same lock. IOW, int T = 0; /* can be incremented at any time */ void check_monotony(void) { static int t = 0; lock(SOME_LOCK); BUG(t > T); T = t; unlock(SOME_LOCK); } must work corrrectly (ignoring overflow) even if T is changed without SOME_LOCK. Otherwise, without some sort of synchronization the different results on CPU_1/2 should be fine. Or I am still missing your point? Oleg. -- 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/