Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758538AbXJLIoX (ORCPT ); Fri, 12 Oct 2007 04:44:23 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751122AbXJLIoP (ORCPT ); Fri, 12 Oct 2007 04:44:15 -0400 Received: from embla.aitel.hist.no ([158.38.50.22]:49159 "EHLO embla.aitel.hist.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751406AbXJLIoO (ORCPT ); Fri, 12 Oct 2007 04:44:14 -0400 Message-ID: <470F337A.9090205@aitel.hist.no> Date: Fri, 12 Oct 2007 10:42:34 +0200 From: Helge Hafting User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Jarek Poplawski CC: Nick Piggin , Linux Kernel Mailing List , Linus Torvalds , Andi Kleen Subject: Re: [rfc][patch 3/3] x86: optimise barriers References: <20071012082534.GB1962@ff.dom.local> In-Reply-To: <20071012082534.GB1962@ff.dom.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1490 Lines: 37 Jarek Poplawski wrote: > On 04-10-2007 07:23, Nick Piggin wrote: > >> According to latest memory ordering specification documents from Intel and >> AMD, both manufacturers are committed to in-order loads from cacheable memory >> for the x86 architecture. Hence, smp_rmb() may be a simple barrier. >> > ... > > Great news! > > First it looks like a really great thing that it's revealed at last. > But then... there is probably some confusion: did we have to use > ineffective code for so long? > You could have tried the optimization before, and gotten better performance. But if without solid knowledge that the optimization is _valid_, you risk having a kernel that performs great but suffer the occational glitch and therefore is unstable and crash the machine "now and then". This sort of thing can't really be figured out by experimentation, because the bad cases might happen only with some processors, some combinations of memory/chipsets, or with some minimum number of processors. Such problems can be very hard to find, especially considering that other plain bugs also cause crashes. Therefore, the "ineffective code" was used because it was the only safe alternative. Now we know, so now we may optimize. Helge Hafting - 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/