Re: bit fields && data tearing
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Peter Hurley <peter@xxxxxxxxxxxxxxxxxx>
- Subject: Re: bit fields && data tearing
- From: One Thousand Gnomes <gnomes@xxxxxxxxxxxxxxxxxxx>
- Date: Thu, 4 Sep 2014 17:50:44 +0100
- Cc: Jakub Jelinek <jakub@xxxxxxxxxx>, Mikael Pettersson <mikpelinux@xxxxxxxxx>, Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>, "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>, Richard Henderson <rth@xxxxxxxxxxx>, Oleg Nesterov <oleg@xxxxxxxxxx>, Miroslav Franc <mfranc@xxxxxxxxxx>, Paul Mackerras <paulus@xxxxxxxxx>, linuxppc-dev@xxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-arch@xxxxxxxxxxxxxxx, Tony Luck <tony.luck@xxxxxxxxx>, linux-ia64@xxxxxxxxxxxxxxx
- In-reply-to: <540859EC.5000407@hurleysoftware.com>
- List-id: <linux-ia64.vger.kernel.org>
- Organization: Intel Corporation
- References: <20140712181328.GA8738@redhat.com> <54079B70.4050200@hurleysoftware.com> <1409785893.30640.118.camel@pasglop> <21512.10628.412205.873477@gargle.gargle.HOWL> <20140904090952.GW17454@tucnak.redhat.com> <540859EC.5000407@hurleysoftware.com>
> 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.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Index of Archives]
[Linux Kernel]
[Sparc Linux]
[DCCP]
[Linux ARM]
[Yosemite News]
[Linux SCSI]
[Linux x86_64]
[Linux for Ham Radio]