Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965117AbWIKXTd (ORCPT ); Mon, 11 Sep 2006 19:19:33 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S965119AbWIKXT3 (ORCPT ); Mon, 11 Sep 2006 19:19:29 -0400 Received: from gate.crashing.org ([63.228.1.57]:9909 "EHLO gate.crashing.org") by vger.kernel.org with ESMTP id S965117AbWIKXTU (ORCPT ); Mon, 11 Sep 2006 19:19:20 -0400 Subject: Re: [RFC] MMIO accessors & barriers documentation From: Benjamin Herrenschmidt To: Roland Dreier Cc: Jeff Garzik , Jesse Barnes , Linux Kernel list , Alan Cox , "David S. Miller" , Paul Mackerras , Linus Torvalds , Andrew Morton , Segher Boessenkool In-Reply-To: References: <1157947414.31071.386.camel@localhost.localdomain> <200609111139.35344.jbarnes@virtuousgeek.org> <1158011129.3879.69.camel@localhost.localdomain> <4505DB10.7080807@pobox.com> <1158015394.3879.82.camel@localhost.localdomain> Content-Type: text/plain Date: Tue, 12 Sep 2006 09:18:51 +1000 Message-Id: <1158016731.15465.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1493 Lines: 33 > where next_eqe_sw() checks a "valid" bit of a 32-byte event queue > entry that is DMA-ed into memory by the device. The device is careful > to write the valid bit (byte actually) last, but on PowerPC 970 > without the rmb(), we actually saw the CPU reordering the read of > eqe->type (which is another field of the EQ entry written by the > device) so it happened before the entry was valid, but then executing > the check of the valid bit far enough into the future so that the > entry tested as valid. Yes, the CPU can perfectly load it before the previous load, indeed. I'm sure that wouldn't be powerpc specific. In this case, it would be a speculative load (since there is a data dependency, thus you would think it's ok, but it's not on CPUs that do speculative execution). > This isn't that surprising: if you had two CPUs, with one CPU writing > into a queue and the other CPU polling the queue, you would obviously > need smp_rmb() on the CPU doing the reading. But somehow it's not > quite as obvious when a device plays the role of one of the CPUs. > > Of course there's no MMIO anywhere in sight here, so this isn't > directly applicable I guess. It's a "normal" case memory barrier in this case. Same as for SMP. Yup. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/