From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752285AbbEDUlE (ORCPT ); Mon, 4 May 2015 16:41:04 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]:49234 "EHLO e34.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751036AbbEDUk5 (ORCPT ); Mon, 4 May 2015 16:40:57 -0400 Date: Mon, 4 May 2015 13:40:50 -0700 From: "Paul E. McKenney" To: Rik van Riel Cc: Paolo Bonzini , Ingo Molnar , Andy Lutomirski , "linux-kernel@vger.kernel.org" , X86 ML , williams@redhat.com, Andrew Lutomirski , fweisbec@redhat.com, Peter Zijlstra , Heiko Carstens , Thomas Gleixner , Ingo Molnar , Linus Torvalds Subject: Re: question about RCU dynticks_nesting Message-ID: <20150504204050.GH5381@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <5543C05E.9040209@redhat.com> <20150501184025.GA2114@gmail.com> <5543CFE5.1030509@redhat.com> <20150502052733.GA9983@gmail.com> <55473B47.6080600@redhat.com> <55479749.7070608@redhat.com> <5547C1DC.10802@redhat.com> <20150504193923.GX5381@linux.vnet.ibm.com> <5547CF86.9060201@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5547CF86.9060201@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15050420-0017-0000-0000-00000A84DC93 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 04, 2015 at 03:59:02PM -0400, Rik van Riel wrote: > On 05/04/2015 03:39 PM, Paul E. McKenney wrote: > > On Mon, May 04, 2015 at 03:00:44PM -0400, Rik van Riel wrote: > > >> In case of the non-preemptible RCU, we could easily also > >> increase current->rcu_read_lock_nesting at the same time > >> we increase the preempt counter, and use that as the > >> indicator to test whether the cpu is in an extended > >> rcu quiescent state. That way there would be no extra > >> overhead at syscall entry or exit at all. The trick > >> would be getting the preempt count and the rcu read > >> lock nesting count in the same cache line for each task. > > > > But in non-preemptible RCU, we have PREEMPT=n, so there is no preempt > > counter in production kernels. Even if there was, we have to sample this > > on other CPUs, so the overhead of preempt_disable() and preempt_enable() > > would be where kernel entry/exit is, so I expect that this would be a > > net loss in overall performance. > > CONFIG_PREEMPT_RCU seems to be independent of CONFIG_PREEMPT. > Not sure why, but they are :) Well, they used to be independent. But the "depends" clauses force them. You cannot have TREE_RCU unless !PREEMPT && SMP. > >> In case of the preemptible RCU scheme, we would have to > >> examine the per-task state (under the runqueue lock) > >> to get the current task info of all CPUs, and in > >> addition wait for the blkd_tasks list to empty out > >> when doing a synchronize_rcu(). > >> > >> That does not appear to require special per-cpu > >> counters; examining the per-cpu rdp and the lists > >> inside it, with the rnp->lock held if doing any > >> list manipulation, looks like it would be enough. > >> > >> However, the current code is a lot more complicated > >> than that. Am I overlooking something obvious, Paul? > >> Maybe something non-obvious? :) > > > > Ummm... The need to maintain memory ordering when sampling task > > state from remote CPUs? > > > > Or am I completely confused about what you are suggesting? > > > > That said, are you chasing a real system-visible performance issue > > that you tracked to RCU's dyntick-idle system? > > The goal is to reduce the syscall overhead of nohz_full. > > Part of the overhead is in the vtime updates, part of it is > in the way RCU extended quiescent state is tracked. OK, as long as it is actual measurements rather than guesswork. Thanx, Paul