Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933113AbbDISIP (ORCPT ); Thu, 9 Apr 2015 14:08:15 -0400 Received: from mail-ie0-f169.google.com ([209.85.223.169]:34765 "EHLO mail-ie0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755680AbbDISIM (ORCPT ); Thu, 9 Apr 2015 14:08:12 -0400 MIME-Version: 1.0 In-Reply-To: <20150409175652.GI6464@linux.vnet.ibm.com> References: <1428521960-5268-1-git-send-email-jason.low2@hp.com> <1428521960-5268-3-git-send-email-jason.low2@hp.com> <20150409053725.GB13871@gmail.com> <1428561611.3506.78.camel@j-VirtualBox> <20150409075311.GA4645@gmail.com> <20150409175652.GI6464@linux.vnet.ibm.com> Date: Thu, 9 Apr 2015 11:08:11 -0700 X-Google-Sender-Auth: pXirwCLKu4unlWuozavj_Qi5lmQ Message-ID: Subject: Re: [PATCH 2/2] locking/rwsem: Use a return variable in rwsem_spin_on_owner() From: Linus Torvalds To: Paul McKenney Cc: Ingo Molnar , Jason Low , Peter Zijlstra , Davidlohr Bueso , Tim Chen , Aswin Chandramouleeswaran , LKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1604 Lines: 35 On Thu, Apr 9, 2015 at 10:56 AM, Paul E. McKenney wrote: > > And if such long-term spins are likely, I cannot resist asking if this > should be instead using SRCU. If you have your own srcu_struct, you > get to delay your own SRCU grace periods as long as you want. ;-) No, this is plain RCU, and it is only needed because the 'struct task_struct' is RCU-allocated, and we do an optimistic access of that 'owner->on_cpu' without actually holding any locks. And even *that* wouldn't be needed if it wasn't for DEBUG_PAGEALLOC. We could just access stale memory. I wonder if we should get rid of the whole RCU thing (which does add overhead to a potentially critical piece of code), and replace it with a new "optimistic_kernel_read()" function that basically just does a memory read with an exception table entry (ie like __get_user(), but without any of the user access overhead - no clac etc), so that if we fault due to DEBUG_PAGEALLOC it just ignores the fault. Hmm? I think there might be a few other places that currently get RCU read locks just because they want to do an optimistic read of something that migth be going away from under them. The pointer is a known-safe kernel pointer - it's just that it was "known safe" a few instructions ago, and might be rcu-free'd at any time. Linus -- 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/