Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755502AbZALRdf (ORCPT ); Mon, 12 Jan 2009 12:33:35 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752642AbZALRdX (ORCPT ); Mon, 12 Jan 2009 12:33:23 -0500 Received: from ug-out-1314.google.com ([66.249.92.173]:62459 "EHLO ug-out-1314.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751146AbZALRdV (ORCPT ); Mon, 12 Jan 2009 12:33:21 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Pnz6p0cKUMH6O/hGR8Lq4a//oRT1ot8JWhFbCBf5nIrzaRa0TGwh3jGz/iL/v4XPjL mlIAzZcSIIWdNtE6e4KSg6RSHvCCUdOv5Z+aqkrs2maQYXXERdSOIAzOftDkI8o2yaAh 0teKtUqUYdVhtmqtLAanjskrgKTiQdIl0xYIw= Message-ID: <496B7ED7.3010601@panasas.com> Date: Mon, 12 Jan 2009 19:33:11 +0200 From: Boaz Harrosh User-Agent: Thunderbird/3.0a2 (X11; 2008072418) MIME-Version: 1.0 To: Peter Zijlstra CC: Linus Torvalds , Ingo Molnar , "Paul E. McKenney" , Gregory Haskins , Matthew Wilcox , Andi Kleen , Chris Mason , Andrew Morton , Linux Kernel Mailing List , linux-fsdevel , linux-btrfs , Thomas Gleixner , Nick Piggin , Peter Morreale , Sven Dietrich , Dmitry Adamushko Subject: Re: [PATCH -v8][RFC] mutex: implement adaptive spinning References: <1231774622.4371.96.camel@laptop> <1231780581.4371.193.camel@laptop> In-Reply-To: <1231780581.4371.193.camel@laptop> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2098 Lines: 47 Peter Zijlstra wrote: > On Mon, 2009-01-12 at 08:20 -0800, Linus Torvalds wrote: >> On Mon, 12 Jan 2009, Linus Torvalds wrote: >>> You made it back into the locked version. >> Btw, even if you probably had some reason for this, one thing to note is >> that I think Chris' performance testing showed that the version using a >> lock was inferior to his local btrfs hack, while the unlocked version >> actually beat his hack. >> >> Maybe I misunderstood his numbers, though. But if I followed that sub-part >> of the test right, it really means that the locked version is pointless - >> it will never be able to replace peoples local hacks for this same thing, >> because it just doesn't give the performance people are looking for. >> >> Since the whole (and _only_) point of this thing is to perform well, >> that's a big deal. > > Like said in reply to Chris' email, I just wanted to see if fairness was > worth the effort, because the pure unlocked spin showed significant > unfairness (and I know some people really care about some level of > fairness). > Which brings me back to my initial reaction to this work. Do we need two flavors of Mutex? some program sections need Fairness, some need performance. Some need low-latency, some need absolute raw CPU power. Because at the end of the day spinning in a saturated CPU work-load that does not care about latency, eats away cycles that could be spent on computation. Think multi-threaded video processing for example. Thing I would like to measure is 1 - how many times we spin and at the end get a lock 2 - how many times we spin and at the end sleep. 3 - how many times we sleep like before. vs. In old case CPU spent on scheduling. Just to see if we are actually loosing cycles at the end. > Initial testing with the simple test-mutex thing didn't show too bad > numbers. > Boaz -- 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/