[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140815142601.GA13222@redhat.com>
Date: Fri, 15 Aug 2014 16:26:01 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Frederic Weisbecker <fweisbec@...il.com>
Cc: Rik van Riel <riel@...hat.com>,
LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>,
Frank Mayhar <fmayhar@...gle.com>,
Frederic Weisbecker <fweisbec@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Sanjay Rao <srao@...hat.com>,
Larry Woodman <lwoodman@...hat.com>
Subject: Re: [PATCH RFC] time,signal: protect resource use statistics with
seqlock
On 08/15, Frederic Weisbecker wrote:
>
> 2014-08-14 16:39 GMT+02:00 Oleg Nesterov <oleg@...hat.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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists