Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755788AbbDIQrj (ORCPT ); Thu, 9 Apr 2015 12:47:39 -0400 Received: from mail-ig0-f181.google.com ([209.85.213.181]:35531 "EHLO mail-ig0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755591AbbDIQrh (ORCPT ); Thu, 9 Apr 2015 12:47:37 -0400 MIME-Version: 1.0 In-Reply-To: <20150409075311.GA4645@gmail.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> Date: Thu, 9 Apr 2015 09:47:36 -0700 X-Google-Sender-Auth: RcEdcFNaRatXgBERnGwMS5O370Y Message-ID: Subject: Re: [PATCH 2/2] locking/rwsem: Use a return variable in rwsem_spin_on_owner() From: Linus Torvalds To: Ingo Molnar , Paul McKenney Cc: 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: 1928 Lines: 48 On Thu, Apr 9, 2015 at 12:53 AM, Ingo Molnar wrote: > > The point is to generally unify the 'out' paths - i.e. to merge it > with the rcu_read_unlock() as well, so that we have really simple > gotos and only a single exit path. Maybe just have the rcu read-locking be done in the *caller* (possibly through using just a helper wrapper function that does nothing but the locking), so that you can just do a simple "return false" in the function itself. That said, it worries me a bit that we do that spinning while holding the RCU read lock in the first place. Yes, we stop spinning if "need_resched()" is set, but what effect - if any - does all of this have on RCU latency? If somebody is waiting for a RCU grace period, I'm not seeing that setting need-resched... At least with CONFIG_PREEMPT_RCU, the read-unlock is *not* just doing a preempt-disable, so it's not necessarily just about need_resched(). It does all the magic with 'rcu_read_unlock_special.s' too.. Adding Paul. From a RCU locking standpoint, the thing is basically (not the real code, edited down): rcu_read_lock(); while (sem->owner == owner) { if (!owner->on_cpu || need_resched()) break; cpu_relax_lowlatency(); } rcu_read_unlock(); so we busy-loop while holding the RCU read lock while sem->owner == owner && owner->on_cpu && !need_resched() is true. That is usually not very long, but we've already had watchdogs go off when we get this wrong, so.. Paul, comments? Are there particular latency concerns wrt CONFIG_PREEMPT_RCU here? Or am I just being silly? 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/