[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130719090328.GA18139@mudshark.cambridge.arm.com>
Date: Fri, 19 Jul 2013 10:03:28 +0100
From: Will Deacon <will.deacon@....com>
To: Stephen Boyd <sboyd@...eaurora.org>
Cc: John Stultz <john.stultz@...aro.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Russell King <linux@....linux.org.uk>,
Catalin Marinas <Catalin.Marinas@....com>,
Christopher Covington <cov@...eaurora.org>
Subject: Re: [PATCH v4 02/17] sched_clock: Use seqcount instead of rolling
our own
On Fri, Jul 19, 2013 at 12:21:15AM +0100, Stephen Boyd wrote:
> We're going to increase the cyc value to 64 bits in the near
> future. Doing that is going to break the custom seqcount
> implementation in the sched_clock code because 64 bit numbers
> aren't guaranteed to be atomic. Replace the cyc_copy with a
> seqcount to avoid this problem.
>
> Cc: Russell King <linux@....linux.org.uk>
> Signed-off-by: Stephen Boyd <sboyd@...eaurora.org>
> ---
> kernel/time/sched_clock.c | 27 ++++++++-------------------
> 1 file changed, 8 insertions(+), 19 deletions(-)
Looks good to me. The current scheme would be very fiddly to extend to
64-bit values on 32-bit architectures without cheap atomic doubleword
accesses.
Acked-by: Will Deacon <will.deacon@....com>
Will
--
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