Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761381AbZAGUki (ORCPT ); Wed, 7 Jan 2009 15:40:38 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1761142AbZAGUkT (ORCPT ); Wed, 7 Jan 2009 15:40:19 -0500 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.122]:33201 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760819AbZAGUkQ (ORCPT ); Wed, 7 Jan 2009 15:40:16 -0500 Date: Wed, 7 Jan 2009 15:40:12 -0500 (EST) From: Steven Rostedt X-X-Sender: rostedt@gandalf.stny.rr.com To: Linus Torvalds cc: Peter Zijlstra , paulmck@linux.vnet.ibm.com, Gregory Haskins , Ingo Molnar , Matthew Wilcox , Andi Kleen , 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: Message-ID: References: <87r63ljzox.fsf@basil.nowhere.org> <20090103191706.GA2002@parisc-linux.org> <1231093310.27690.5.camel@twins> <20090104184103.GE2002@parisc-linux.org> <1231242031.11687.97.camel@twins> <20090106121052.GA27232@elte.hu> <4963584A.4090805@novell.com> <20090106131643.GA15228@elte.hu> <1231248041.11687.107.camel@twins> <49636799.1010109@novell.com> <20090106214229.GD6741@linux.vnet.ibm.com> <1231278275.11687.111.camel@twins> <1231279660.11687.121.camel@twins> <1231281801.11687.125.camel@twins> <1231283778.11687.136.camel@twins> <1231329783.11687.287.camel@twins> <1231347442.11687.344.camel@twins> 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: 1583 Lines: 36 On Wed, 7 Jan 2009, Linus Torvalds wrote: > > So we can do all that locklessly and optimistically, just going back and > verifying the results later. This is why "thread_info" is actually a > better thing to use than "task_struct" - we can look up the cpu in it with > a simple dereference. We knew the pointer _used_ to be valid, so in any > normal situation, it will never page fault (and if you have > CONFIG_DEBUG_PAGEALLOC and hit a very unlucky race, then performance isn't > your concern anyway: we just need to make the page fault be non-lethal ;) Wow, and I thought I do some crazy things with side effects of different kernel characteristics. So basically, since the owner use to be valid and we take the cpu number directly from the thread_info struct, we do not need to worry about page faulting. Next comes the issue to know if the owner is still running. Wouldn't we need to do something like if (task_thread_info(cpu_rq(cpu)->curr) == owner) I guess that would have the same characteristic, that even if the task struct of cpu_rq(cpu)->curr was freed, we can still reference the thread_info. Although, we might get garbage, but we don't care. I understand that this should not be a problem, but I'm afraid it will give me nightmares at night. ;-) God that code had better be commented well. -- 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/