[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5408C0AB.6050801@hurleysoftware.com>
Date: Thu, 04 Sep 2014 15:42:35 -0400
From: Peter Hurley <peter@...leysoftware.com>
To: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
CC: Jakub Jelinek <jakub@...hat.com>,
Mikael Pettersson <mikpelinux@...il.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Richard Henderson <rth@...ddle.net>,
Oleg Nesterov <oleg@...hat.com>,
Miroslav Franc <mfranc@...hat.com>,
Paul Mackerras <paulus@...ba.org>,
linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
linux-arch@...r.kernel.org, Tony Luck <tony.luck@...el.com>,
linux-ia64@...r.kernel.org
Subject: Re: bit fields && data tearing
On 09/04/2014 12:50 PM, One Thousand Gnomes wrote:
>> Besides updating the documentation, it may make sense to do something
>> arch-specific. Just bumping out storage on arches that don't need it
>> seems wasteful, as does generating bus locks on arches that don't need it.
>> Unfortunately, the code churn looks unavoidable.
>
> The arch specific is pretty much set_bit and friends. Bus locks on a
> locally owned cache line should not be very expensive on anything vaguely
> modern, while uniprocessor boxes usually only have to generate set_bit
> as a single instruction so it is interrupt safe.
Or we could give up on the Alpha.
It's not just the non-atomic bytes; we could do away with the
read_barrier_depends() which hardly any code gets correctly anyway.
Regards,
Peter Hurley
--
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