[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140115080753.GW31570@twins.programming.kicks-ass.net>
Date: Wed, 15 Jan 2014 09:07:53 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Richard Henderson <rth@...ddle.net>,
Matt Turner <mattst88@...il.com>,
Daniel J Blueman <daniel@...ascale.com>,
Waiman Long <waiman.long@...com>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Ivan Kokshaysky <ink@...assic.park.msu.ru>
Subject: Re: [PATCH v8 4/4] qrwlock: Use smp_store_release() in write_unlock()
On Tue, Jan 14, 2014 at 06:39:58PM -0800, Paul E. McKenney wrote:
> > If you just want to do a store release, on alpha you'd want to
> > implement that as a full memory barrier followed by a store. It
> > doesn't get the advantage of a real release consistency model, but at
> > least it's not doing an external bus access. But you can only do that
> > store as a 4-byte or 8-byte store.on the older alphas (byte and word
> > stores work on newer ones).
> >
> > Of course, it's entirely possible that nobody cares..
>
> That would be my hope. ;-)
>
> If nobody cares about Alpha period, it is easy. However, the last time
> that I tried that approach, they sent me a URL of a wiki showing Alpha
> systems still running mainline. But a slow-but-working approach for
> Alpha does seem reasonable, even for those still running Linux on Alpha.
Well, if they're all EV56 or later we're still good as they can actually
do what we need.
But I don't think a ll/sc implementation of the store_release can even
work, because in that case all users of the other bytes also need a
ll/sc around them but how are we to know about them?
So the only real way to allow store_release on 8/16 bit values is by
removing all Alpha support _pre_ EV56 :/
--
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