From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753255AbdLEXkF (ORCPT ); Tue, 5 Dec 2017 18:40:05 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:49428 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753043AbdLEXkD (ORCPT ); Tue, 5 Dec 2017 18:40:03 -0500 Date: Tue, 5 Dec 2017 15:39:55 -0800 From: "Paul E. McKenney" To: "Michael S. Tsirkin" Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, mingo@kernel.org, jiangshanlai@gmail.com, dipankar@in.ibm.com, akpm@linux-foundation.org, mathieu.desnoyers@efficios.com, josh@joshtriplett.org, tglx@linutronix.de, rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com, fweisbec@gmail.com, oleg@redhat.com, Jason Wang , kvm@vger.kernel.org, virtualization@lists.linux-foundation.org, netdev@vger.kernel.org Subject: Re: [PATCH tip/core/rcu 21/21] drivers/vhost: Remove now-redundant read_barrier_depends() Reply-To: paulmck@linux.vnet.ibm.com References: <20171205183946.GP3165@worktop.lehotels.local> <20171205204928-mutt-send-email-mst@kernel.org> <20171205191733.GQ3165@worktop.lehotels.local> <20171205212053-mutt-send-email-mst@kernel.org> <20171205193339.GP7829@linux.vnet.ibm.com> <20171205215020-mutt-send-email-mst@kernel.org> <20171205200801.GR7829@linux.vnet.ibm.com> <20171205222857-mutt-send-email-mst@kernel.org> <20171205215700.GV3165@worktop.lehotels.local> <20171206000541-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171206000541-mutt-send-email-mst@kernel.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17120523-2213-0000-0000-000002465282 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008156; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000243; SDB=6.00955986; UDB=6.00483206; IPR=6.00736024; BA=6.00005729; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00018370; XFM=3.00000015; UTC=2017-12-05 23:40:01 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17120523-2214-0000-0000-0000585C3AFB Message-Id: <20171205233955.GW7829@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-12-05_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1712050335 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 06, 2017 at 12:09:36AM +0200, Michael S. Tsirkin wrote: > On Tue, Dec 05, 2017 at 10:57:00PM +0100, Peter Zijlstra wrote: > > On Tue, Dec 05, 2017 at 11:24:49PM +0200, Michael S. Tsirkin wrote: > > > READ_ONCE is really all over the place (some code literally replaced all > > > memory accesses with READ/WRITE ONCE). > > > > Yeah, so? > > Oh my point was I can't just look for READ_ONCE and go > *that's the pair*. there are too many of these. > At Paul's suggestion I will document the pairing *this read once has a > barrier that is paired with that barrier*. > > > Complain to the compiler people for forcing us into that. > > In some cases when you end up with all accesses > going through read/write once volatile just might better. That is in fact what the jiffies counter does. But you lose READ_ONCE()'s automatic handling of DEC Alpha when you take that approach. > > > Would an API like WRITE_POINTER()/smp_store_pointer make sense, > > > and READ_POINTER for symmetry? > > > > No, the whole point of the exercise was to get away from the fact that > > dependent loads are special. > > It's a pity that dependent stores are still special. We can make READ_ONCE() not be special at zero cost on non-Alpha systems, but both smp_wmb() and smp_store_release() are decidedly not free of added overhead. Thanx, Paul