[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090114112158.GA8625@elte.hu>
Date: Wed, 14 Jan 2009 12:21:58 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Chris Mason <chris.mason@...cle.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Gregory Haskins <ghaskins@...ell.com>,
Matthew Wilcox <matthew@....cx>,
Andi Kleen <andi@...stfloor.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
linux-btrfs <linux-btrfs@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Nick Piggin <npiggin@...e.de>,
Peter Morreale <pmorreale@...ell.com>,
Sven Dietrich <SDietrich@...ell.com>,
Dmitry Adamushko <dmitry.adamushko@...il.com>
Subject: Re: [PATCH -v9][RFC] mutex: implement adaptive spinning
* Chris Mason <chris.mason@...cle.com> wrote:
> v10 is better that not spinning, but its in the 5-10% range. So, I've
> been trying to find ways to close the gap, just to understand exactly
> where it is different.
>
> If I take out:
> /*
> * If there are pending waiters, join them.
> */
> if (!list_empty(&lock->wait_list))
> break;
>
>
> v10 pops dbench 50 up to 1800MB/s. The other tests soundly beat my
> spinning and aren't less fair. But clearly this isn't a good solution.
i think since we already decided that it's ok to be somewhat unfair (_all_
batching constructs introduce unfairness, so the question is never 'should
we?' but 'by how much?'), we should just take this out and enjoy the speed
...
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists