Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759596AbXFUURE (ORCPT ); Thu, 21 Jun 2007 16:17:04 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752070AbXFUUQy (ORCPT ); Thu, 21 Jun 2007 16:16:54 -0400 Received: from smtp2.linux-foundation.org ([207.189.120.14]:48756 "EHLO smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752508AbXFUUQx (ORCPT ); Thu, 21 Jun 2007 16:16:53 -0400 Date: Thu, 21 Jun 2007 13:14:52 -0700 (PDT) From: Linus Torvalds To: Ingo Molnar cc: Eric Dumazet , Chuck Ebbert , Jarek Poplawski , Miklos Szeredi , chris@atlee.ca, linux-kernel@vger.kernel.org, tglx@linutronix.de, akpm@linux-foundation.org Subject: Re: [BUG] long freezes on thinkpad t60 In-Reply-To: <20070621200941.GB22303@elte.hu> Message-ID: References: <20070620093612.GA1626@ff.dom.local> <20070621073031.GA683@elte.hu> <20070621160817.GA22897@elte.hu> <467AAB04.2070409@redhat.com> <20070621202917.a2bfbfc7.dada1@cosmosbay.com> <20070621200941.GB22303@elte.hu> 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: 1666 Lines: 50 On Thu, 21 Jun 2007, Ingo Molnar wrote: > > * Linus Torvalds wrote: > > > If somebody can actually come up with a sequence where we have > > spinlock starvation, and it's not about an example of bad locking, and > > nobody really can come up with any other way to fix it, we may > > eventually have to add the notion of "fair spinlocks". > > there was one bad case i can remember: the spinlock debugging code had a > trylock open-coded loop and on certain Opterons CPUs were starving each > other. But this is a perfect example of exactly what I'm talking about: THAT CODE IS HORRIBLY BUGGY! It's not the spinlocks that are broken, it's that damn code. > for (;;) { > for (i = 0; i < loops; i++) { > if (__raw_write_trylock(&lock->raw_lock)) > return; > __delay(1); > } What a piece of crap. Anybody who ever waits for a lock by busy-looping over it is BUGGY, dammit! The only correct way to wait for a lock is: (a) try it *once* with an atomic r-m-w (b) loop over just _reading_ it (and something that implies a memory barrier, _not_ "__delay()". Use "cpu_relax()" or "smp_rmb()") (c) rinse and repeat. and code like the above should just be shot on sight. So don't blame the spinlocks or the hardware for crap code. Linus - 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/