Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762760AbZAGXJw (ORCPT ); Wed, 7 Jan 2009 18:09:52 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751930AbZAGXJh (ORCPT ); Wed, 7 Jan 2009 18:09:37 -0500 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.124]:40659 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752187AbZAGXJg (ORCPT ); Wed, 7 Jan 2009 18:09:36 -0500 Date: Wed, 7 Jan 2009 18:09:32 -0500 (EST) From: Steven Rostedt X-X-Sender: rostedt@gandalf.stny.rr.com To: Gregory Haskins cc: Ingo Molnar , Andi Kleen , Matthew Wilcox , Linus Torvalds , Peter Zijlstra , paulmck@linux.vnet.ibm.com, Chris Mason , Andrew Morton , Linux Kernel Mailing List , linux-fsdevel , linux-btrfs , Thomas Gleixner , Nick Piggin , Peter Morreale , Sven Dietrich Subject: Re: [PATCH -v5][RFC]: mutex: implement adaptive spinning In-Reply-To: <4965331E.8090202@novell.com> Message-ID: References: <1231283778.11687.136.camel@twins> <1231329783.11687.287.camel@twins> <1231347442.11687.344.camel@twins> <20090107210923.GV2002@parisc-linux.org> <20090107213924.GP496@one.firstfloor.org> <49652C7C.3000909@novell.com> <20090107223317.GB27629@elte.hu> <4965331E.8090202@novell.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1719 Lines: 46 On Wed, 7 Jan 2009, Gregory Haskins wrote: > Hi Ingo, > > Ingo Molnar wrote: > > * Gregory Haskins wrote: > > > > > >> Can I ask a simple question in light of all this discussion? > >> > >> "Is get_task_struct() really that bad?" > >> > > > > it dirties a cacheline and it also involves atomics. > > > Yes, understood. But we should note we are always going to be talking > about thrashing caches here since we are ultimately having one CPU > observe another. There's no way to get around that. I understand that > there are various degrees of this occurring, and I have no doubt that > the proposed improvements strive to achieve a reduction of that. My > question is really targeted at "at what cost". > > Don't get me wrong. I am not advocating going back to get/put-task per > se. I am simply asking the question of whether we have taken the design > off into the weeds having lost sight of the actual requirements and/or > results. Its starting to smell like we have. This is just a friendly > reality check. Feel free to disregard. ;) What would be interesting is various benchmarks against all three. 1) no mutex spinning. 2) get_task_struct() implementation. 3) spin_or_sched implementation. I believe that 2 happens to be the easiest to understand. No need to know about the behavior of freed objects. If we see no or negligible improvement between 2 and 3 on any benchmark, then I say we stick with 2. -- Steve -- 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/