From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030347AbXCCRTs (ORCPT ); Sat, 3 Mar 2007 12:19:48 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030344AbXCCRTs (ORCPT ); Sat, 3 Mar 2007 12:19:48 -0500 Received: from dvhart.com ([64.146.134.43]:54757 "EHLO dvhart.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030347AbXCCRTr (ORCPT ); Sat, 3 Mar 2007 12:19:47 -0500 Message-ID: <45E9AD74.4060704@mbligh.org> Date: Sat, 03 Mar 2007 09:16:36 -0800 From: "Martin J. Bligh" User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Christoph Lameter Cc: William Lee Irwin III , Andrew Morton , Rik van Riel , Bill Irwin , Mel Gorman , npiggin@suse.de, mingo@elte.hu, jschopp@austin.ibm.com, arjan@infradead.org, torvalds@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: The performance and behaviour of the anti-fragmentation related patches References: <20070302093501.34c6ef2a.akpm@linux-foundation.org> <45E8624E.2080001@redhat.com> <20070302100619.cec06d6a.akpm@linux-foundation.org> <45E86BA0.50508@redhat.com> <20070302211207.GJ10643@holomorphy.com> <45E894D7.2040309@redhat.com> <20070302135243.ada51084.akpm@linux-foundation.org> <45E89F1E.8020803@redhat.com> <20070302142256.0127f5ac.akpm@linux-foundation.org> <20070303003319.GB23573@holomorphy.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Christoph Lameter wrote: > On Fri, 2 Mar 2007, William Lee Irwin III wrote: > >> On Fri, Mar 02, 2007 at 02:22:56PM -0800, Andrew Morton wrote: >>> Opterons seem to be particularly prone to lock starvation where a cacheline >>> gets captured in a single package for ever. >> AIUI that phenomenon is universal to NUMA. Maybe it's time we >> reexamined our locking algorithms in the light of fairness >> considerations. > > This is a phenomenon that is usually addressed at the cache logic level. > Its a hardware maturation issue. A certain package should not be allowed > to hold onto a cacheline forever and other packages must have a mininum > time when they can operate on that cacheline. That'd be nice. Unfortunately we're stuck in the real world with real hardware, and the situation is likely to remain thus for quite some time ... M.