From: Nikita Danilov <Nikita@Namesys.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16077.52259.718519.389903@laputa.namesys.com>
Date: Fri, 23 May 2003 11:22:11 +0400
To: "Robert White" <rwhite@casabyte.com>
Cc: "Nick Piggin" <piggin@cyberone.com.au>, <elladan@eskimo.com>,
       "Rik van Riel" <riel@imladris.surriel.com>,
       "David Woodhouse" <dwmw2@infradead.org>, <ptb@it.uc3m.es>,
       "William Lee Irwin III" <wli@holomorphy.com>,
       "Martin J. Bligh" <mbligh@aracnet.com>, <linux-kernel@vger.kernel.org>,
       <root@chaos.analogic.com>
Subject: Re: recursive spinlocks. Shoot.
In-Reply-To: <PEEPIDHAKMCGHDBJLHKGEEKJCMAA.rwhite@casabyte.com>
References: <3ECC4C3A.9000903@cyberone.com.au>
	<PEEPIDHAKMCGHDBJLHKGEEKJCMAA.rwhite@casabyte.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1148
Lines: 57

Robert White writes:
 > This will, hopefully, be my out-comment on this thread.
 > 

[...]

 > 
 > 4) All locks (spin or otherwise) should obviously be held for the shortest
 > amount of time reasonably possible which still produces the correct result.
 > 
 > If this needs explaining...  8-)

It surely does.

Consider two loops:

(1)

spin_lock(&lock);
list_for_each_entry(item, ...) {
  do something with item;
}
spin_unlock(&lock);

versus

(2)

list_for_each_entry(item, ...) {
  spin_lock(&lock);
  do something with item;
  spin_unlock(&lock);
}

and suppose they both are equally correct. Now, in (2) total amount of
time &lock is held is smaller than in (1), but (2) will usually perform
worse on SMP, because:

. spin_lock() is an optimization barrier

. taking even un-contended spin lock is an expensive operation, because
of the cache coherency issues.

 > 

[...]

 > 
 > Rob.
 > 

Nikita.
-
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/