2014-08-14 16:39 GMT+02:00 Oleg Nesterov <o...@redhat.com>: > On 08/14, Frederic Weisbecker wrote: >> >> 2014-08-14 3:57 GMT+02:00 Rik van Riel <r...@redhat.com>: >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA1 >> > >> > On 08/13/2014 08:43 PM, Frederic Weisbecker wrote: >> >> On Wed, Aug 13, 2014 at 05:03:24PM -0400, Rik van Riel wrote: >> >> >> >> I'm worried about such lockless solution based on RCU or read >> >> seqcount because we lose the guarantee that an update is >> >> immediately visible by all subsequent readers. >> >> >> >> Say CPU 0 updates the thread time and both CPU 1 and CPU 2 right >> >> after that call clock_gettime(), with the spinlock we were >> >> guaranteed to see the new update. Now with a pure seqlock read >> >> approach, we guarantee a read sequence coherency but we don't >> >> guarantee the freshest update result. >> >> >> >> So that looks like a source of non monotonic results. >> > >> > Which update are you worried about, specifically? >> > >> > The seq_write_lock to update the usage stat in p->signal will lock out >> > the seqlock read side used to check those results. >> > >> > Is there another kind of thing read by cpu_clock_sample_group that you >> > believe is not excluded by the seq_lock? >> >> 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. -- 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/
