This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Fri Apr 26 21:12:03 2024 Delivery-date: Tue, 14 Mar 2006 22:12:13 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932458AbWCNVLj (ORCPT ); Tue, 14 Mar 2006 16:11:39 -0500 Received: from odyssey.analogic.com ([204.178.40.5]:53002 "EHLO odyssey.analogic.com") by vger.kernel.org with ESMTP id S932457AbWCNVLi convert rfc822-to-8bit (ORCPT ); Tue, 14 Mar 2006 16:11:38 -0500 Received: from chaos.analogic.com ([10.112.50.11]) by phoenix.analogic.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Mar 2006 16:11:36 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from chaos.analogic.com (localhost [127.0.0.1]) by chaos.analogic.com (8.12.11/8.12.11) with ESMTP id k2ELBaWj009250; Tue, 14 Mar 2006 16:11:36 -0500 Received: (from linux-os@localhost) by chaos.analogic.com (8.12.11/8.12.11/Submit) id k2ELBaMU009249; Tue, 14 Mar 2006 16:11:36 -0500 In-Reply-To: <31016.1142368317@warthog.cambridge.redhat.com> X-OriginalArrivalTime: 14 Mar 2006 21:11:36.0985 (UTC) FILETIME=[E1334090:01C647AB] content-class: urn:content-classes:message Subject: Re: [PATCH] Document Linux's memory barriers [try #4] Date: Tue, 14 Mar 2006 16:11:36 -0500 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] Document Linux's memory barriers [try #4] Thread-Index: AcZHq+E86K9IKhfUQe6G7AOSL2AFkw== References: <878xrecypp.fsf@javad.com> <16835.1141936162@warthog.cambridge.redhat.com> <31016.1142368317@warthog.cambridge.redhat.com> From: "linux-os \(Dick Johnson\)" To: "David Howells" Cc: "Sergei Organov" , Reply-To: "linux-os \(Dick Johnson\)" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 14 Mar 2006, David Howells wrote: > Sergei Organov wrote: > >> "You can prevent an `asm' instruction from being deleted by writing the >> keyword `volatile' after the `asm'. [...] >> The `volatile' keyword indicates that the instruction has important >> side-effects. GCC will not delete a volatile `asm' if it is reachable. >> (The instruction can still be deleted if GCC can prove that >> control-flow will never reach the location of the instruction.) *Note >> that even a volatile `asm' instruction can be moved relative to other >> code, including across jump instructions.*" > > Ummm... If "asm volatile" statements don't form compiler barriers, then how do > you specify a compiler barrier? Or is that what the "memory" bit in: > > #define barrier() __asm__ __volatile__("": : :"memory") > > does? > > David Yeh. This is the problem (restated) that I mentioned the other day when you must do a dummy read of the PCI/Bus to flush all the writes, to some variable that gcc can't decide isn't important. That's why (void)readl(PCI_STATUS) won't work (with gcc 3.3.3 anyway). Some assignment needs to be made to something gcc thinks is important or it might be moved or removed altogether. #define barrier() __asm__ __volatile__("": : :"memory") Just tells the compiler that memory may have been modified. Therefore, it will re-read any variables that might be setting in registers, before it uses them. This is very useful since it basically makes all variables temporarily "volatile" in its effects. Cheers, Dick Johnson Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips). Warning : 98.36% of all statistics are fiction, book release in April. _  **************************************************************** The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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/