From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boaz Harrosh Subject: Re: [PATCH -v8][RFC] mutex: implement adaptive spinning Date: Mon, 12 Jan 2009 19:33:11 +0200 Message-ID: <496B7ED7.3010601@panasas.com> References: <1231774622.4371.96.camel@laptop> <1231780581.4371.193.camel@laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 To: Peter Zijlstra Return-path: 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 In-Reply-To: <1231780581.4371.193.camel@laptop> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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