Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932992AbbDISQ2 (ORCPT ); Thu, 9 Apr 2015 14:16:28 -0400 Received: from mail-ig0-f173.google.com ([209.85.213.173]:37466 "EHLO mail-ig0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753969AbbDISQZ (ORCPT ); Thu, 9 Apr 2015 14:16:25 -0400 MIME-Version: 1.0 In-Reply-To: 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:16:24 -0700 X-Google-Sender-Auth: uNqxx_PtA9_5SQvzxy_UAQw4pFo 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: 1561 Lines: 47 On Thu, Apr 9, 2015 at 11:08 AM, Linus Torvalds wrote: > > 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. Actually, we could even do something like this: static inline int sem_owner_on_cpu(struct semaphore *sem, struct task_struct *owner) { int on_cpu; #ifdef CONFIG_DEBUG_PAGEALLOC rcu_read_lock(); #endif on_cpu = sem->owner == owner && owner->on_cpu; #ifdef CONFIG_DEBUG_PAGEALLOC rcu_read_unlock(); #endif return on_cpu; } because we really don't need to hold the RCU lock over the whole loop, we just need to validate that the semaphore owner still matches, and if so, check that it's on_cpu. And if CONFIG_DEBUG_PAGEALLOC is set, we don't care about performance *at*all*. We will have worse performance problems than doing some RCU read-locking inside the loop. And if CONFIG_DEBUG_PAGEALLOC isn't set, we don't really care about locking, since at worst we just access stale memory for one iteration. Hmm. It's not pretty, but neither is the current "let's just take a rcu lock that we don't really need over a loop that doesn't have very strict bounding". Comments? 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/