Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761494AbZAGVXs (ORCPT ); Wed, 7 Jan 2009 16:23:48 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751854AbZAGVXi (ORCPT ); Wed, 7 Jan 2009 16:23:38 -0500 Received: from one.firstfloor.org ([213.235.205.2]:41116 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751375AbZAGVXh (ORCPT ); Wed, 7 Jan 2009 16:23:37 -0500 Date: Wed, 7 Jan 2009 22:37:40 +0100 From: Andi Kleen 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 , Steven Rostedt , Nick Piggin , Peter Morreale , Sven Dietrich Subject: Re: [PATCH -v5][RFC]: mutex: implement adaptive spinning Message-ID: <20090107213740.GO496@one.firstfloor.org> References: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1416 Lines: 28 > But we can do that with __get_user(thread_info->cpu) (very unlikely page > fault protection due to the possibility of CONFIG_DEBUG_PAGEALLOC) and > then validating the cpu. It it's in range, we can use it and verify > whether cpu_rq(cpu)->curr has that thread_info. > > 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 ;) The problem with probe_kernel_address() is that it does lots of operations around the access in the hot path (set_fs, pagefault_disable etc.), so i'm not sure that's a good idea. Sure you can probably do better, but that would involve patching all architectures won't it? Ok I suppose you could make an ARCH_HAS_blabla white list, but that wouldn't be exactly pretty. -Andi -- 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/