Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750949AbVJFNqJ (ORCPT ); Thu, 6 Oct 2005 09:46:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750951AbVJFNqJ (ORCPT ); Thu, 6 Oct 2005 09:46:09 -0400 Received: from castle.nmd.msu.ru ([193.232.112.53]:55304 "HELO castle.nmd.msu.ru") by vger.kernel.org with SMTP id S1750949AbVJFNqI (ORCPT ); Thu, 6 Oct 2005 09:46:08 -0400 Message-ID: <20051006174604.B10342@castle.nmd.msu.ru> Date: Thu, 6 Oct 2005 17:46:04 +0400 From: Andrey Savochkin To: Andi Kleen Cc: Kirill Korotaev , linux-kernel@vger.kernel.org, Linus Torvalds , Andrew Morton , xemul@sw.ru, st@sw.ru, discuss@x86-64.org Subject: Re: SMP syncronization on AMD processors (broken?) References: <434520FF.8050100@sw.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from "Andi Kleen" on Thu, Oct 06, 2005 at 03:32:30PM Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1375 Lines: 33 On Thu, Oct 06, 2005 at 03:32:30PM +0200, Andi Kleen wrote: > Kirill Korotaev writes: > > > Please help with a not simple question about spin_lock/spin_unlock on > > SMP archs. The question is whether concurrent spin_lock()'s should > > acquire it in more or less "fair" fashinon or one of CPUs can starve > > any arbitrary time while others do reacquire it in a loop. > > They are not fully fair because of the NUMAness of the system. > Same on many other NUMA systems. > > We considered long ago to use queued locks to avoid this, but > they are quite costly for the uncongested case and never seemed worth it. > > So live with it. Well, it's hard to swallow... It's not about being not fully fair, it's about deadlocks that started to appear after code changes inside retry loops... A practical question is whether there is an "official" way to tell the CPU that it should synchronize with memory, or if you have ideas how to make it less costly than queued locks. A theoretical question is how many places in the kernel use such retry loops that may start to fail some day (or on some machines)... Andrey - 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/