From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754060AbaIDQwK (ORCPT ); Thu, 4 Sep 2014 12:52:10 -0400 Received: from 251.110.2.81.in-addr.arpa ([81.2.110.251]:55545 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751437AbaIDQwI (ORCPT ); Thu, 4 Sep 2014 12:52:08 -0400 Date: Thu, 4 Sep 2014 17:50:44 +0100 From: One Thousand Gnomes To: Peter Hurley Cc: Jakub Jelinek , Mikael Pettersson , Benjamin Herrenschmidt , "Paul E. McKenney" , Richard Henderson , Oleg Nesterov , Miroslav Franc , Paul Mackerras , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Tony Luck , linux-ia64@vger.kernel.org Subject: Re: bit fields && data tearing Message-ID: <20140904175044.4697aee4@alan.etchedpixels.co.uk> In-Reply-To: <540859EC.5000407@hurleysoftware.com> 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> Organization: Intel Corporation X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: One Thousand Gnomes Subject: Re: bit fields && data tearing Date: Thu, 4 Sep 2014 17:50:44 +0100 Message-ID: <20140904175044.4697aee4@alan.etchedpixels.co.uk> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <540859EC.5000407@hurleysoftware.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org Sender: "Linuxppc-dev" To: Peter Hurley Cc: Jakub Jelinek , Mikael Pettersson , Tony Luck , linux-ia64@vger.kernel.org, Oleg Nesterov , linux-kernel@vger.kernel.org, Paul Mackerras , linux-arch@vger.kernel.org, "Paul E. McKenney" , linuxppc-dev@lists.ozlabs.org, Miroslav Franc , Richard Henderson List-Id: linux-arch.vger.kernel.org PiBCZXNpZGVzIHVwZGF0aW5nIHRoZSBkb2N1bWVudGF0aW9uLCBpdCBtYXkgbWFrZSBzZW5zZSB0 byBkbyBzb21ldGhpbmcKPiBhcmNoLXNwZWNpZmljLiBKdXN0IGJ1bXBpbmcgb3V0IHN0b3JhZ2Ug b24gYXJjaGVzIHRoYXQgZG9uJ3QgbmVlZCBpdAo+IHNlZW1zIHdhc3RlZnVsLCBhcyBkb2VzIGdl bmVyYXRpbmcgYnVzIGxvY2tzIG9uIGFyY2hlcyB0aGF0IGRvbid0IG5lZWQgaXQuCj4gVW5mb3J0 dW5hdGVseSwgdGhlIGNvZGUgY2h1cm4gbG9va3MgdW5hdm9pZGFibGUuCgpUaGUgYXJjaCBzcGVj aWZpYyBpcyBwcmV0dHkgbXVjaCBzZXRfYml0IGFuZCBmcmllbmRzLiBCdXMgbG9ja3Mgb24gYQps b2NhbGx5IG93bmVkIGNhY2hlIGxpbmUgc2hvdWxkIG5vdCBiZSB2ZXJ5IGV4cGVuc2l2ZSBvbiBh bnl0aGluZyB2YWd1ZWx5Cm1vZGVybiwgd2hpbGUgdW5pcHJvY2Vzc29yIGJveGVzIHVzdWFsbHkg b25seSBoYXZlIHRvIGdlbmVyYXRlIHNldF9iaXQKYXMgYSBzaW5nbGUgaW5zdHJ1Y3Rpb24gc28g aXQgaXMgaW50ZXJydXB0IHNhZmUuCgpBbGFuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCkxpbnV4cHBjLWRldiBtYWlsaW5nIGxpc3QKTGludXhwcGMtZGV2 QGxpc3RzLm96bGFicy5vcmcKaHR0cHM6Ly9saXN0cy5vemxhYnMub3JnL2xpc3RpbmZvL2xpbnV4 cHBjLWRldg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lxorguk.ukuu.org.uk (7.3.c.8.2.a.e.f.f.f.8.1.0.3.2.0.9.6.0.7.2.3.f.b.0.b.8.0.1.0.0.2.ip6.arpa [IPv6:2001:8b0:bf32:7069:230:18ff:fea2:8c37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id B7ADB1A0068 for ; Fri, 5 Sep 2014 02:51:22 +1000 (EST) Date: Thu, 4 Sep 2014 17:50:44 +0100 From: One Thousand Gnomes To: Peter Hurley Subject: Re: bit fields && data tearing Message-ID: <20140904175044.4697aee4@alan.etchedpixels.co.uk> In-Reply-To: <540859EC.5000407@hurleysoftware.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Cc: Jakub Jelinek , Mikael Pettersson , Tony Luck , linux-ia64@vger.kernel.org, Oleg Nesterov , linux-kernel@vger.kernel.org, Paul Mackerras , linux-arch@vger.kernel.org, "Paul E. McKenney" , linuxppc-dev@lists.ozlabs.org, Miroslav Franc , Richard Henderson List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: One Thousand Gnomes Date: Thu, 04 Sep 2014 16:50:44 +0000 Subject: Re: bit fields && data tearing Message-Id: <20140904175044.4697aee4@alan.etchedpixels.co.uk> List-Id: 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> In-Reply-To: <540859EC.5000407@hurleysoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Peter Hurley Cc: Jakub Jelinek , Mikael Pettersson , Benjamin Herrenschmidt , "Paul E. McKenney" , Richard Henderson , Oleg Nesterov , Miroslav Franc , Paul Mackerras , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Tony Luck , linux-ia64@vger.kernel.org > 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