Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264695AbTIDFJt (ORCPT ); Thu, 4 Sep 2003 01:09:49 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264667AbTIDFJt (ORCPT ); Thu, 4 Sep 2003 01:09:49 -0400 Received: from x35.xmailserver.org ([208.129.208.51]:27819 "EHLO x35.xmailserver.org") by vger.kernel.org with ESMTP id S264695AbTIDFJs (ORCPT ); Thu, 4 Sep 2003 01:09:48 -0400 X-AuthUser: davidel@xmailserver.org Date: Wed, 3 Sep 2003 22:03:59 -0700 (PDT) From: Davide Libenzi X-X-Sender: davide@bigblue.dev.mdolabs.com To: Nagendra Singh Tomar cc: Jamie Lokier , Geert Uytterhoeven , Roman Zippel , Kars de Jong , Linux/m68k kernel mailing list , Linux Kernel Development Subject: Re: x86, ARM, PARISC, PPC, MIPS and Sparc folks please run this In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 978 Lines: 25 On Wed, 3 Sep 2003, Nagendra Singh Tomar wrote: > Jamie, > Just wondered if the store buffer is snooped in some > architectures. In that case I believe the OS need not do anything for > serialization (except for aliases, if they do not hit the same cache line). > In x86 store buffer is not snooped which leads to all these serialization > issues (other CPUs looking at stale value of data which is in the store > buffer of some other CPU). > Pl correct me if I have got anything wrong/ To avoid the so called 'load hazard' (that, BTW, triggers read over writes, that are not allowed in x86) you have two options. Snoop the write buffer or flush it upon L1 miss. Otherwise you might end up getting stale data from L2. - Davide - 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/