From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [PATCH -v5][RFC]: mutex: implement adaptive spinning Date: Wed, 7 Jan 2009 15:18:34 -0800 (PST) Message-ID: References: <1231281801.11687.125.camel@twins> <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> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Andi Kleen , Matthew Wilcox , Steven Rostedt , Peter Zijlstra , paulmck@linux.vnet.ibm.com, Ingo Molnar , Chris Mason , Andrew Morton , Linux Kernel Mailing List , linux-fsdevel , linux-btrfs , Thomas Gleixner , Nick Piggin , Peter Morreale , Sven Dietrich To: Gregory Haskins Return-path: In-Reply-To: List-ID: On Wed, 7 Jan 2009, Linus Torvalds wrote: > > > > "Is get_task_struct() really that bad?" > > Yes. It's an atomic access (two, in fact, since you need to release it > too), which is a huge deal if we're talking about a timing-critical > section of code. There's another issue: you also need to lock the thing that gives you the task pointer in the first place. So it's not sufficient to do get_task_struct(), you also need to do it within a context where you know that the pointer is not going away _while_ you do it. And with the mutexes clearing the ->owner field without even holding the spinlock, that is not a guarantee we can easily get any way. Maybe we'd need to hold the tasklist_lock or something. Linus