From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751800AbbEDQBE (ORCPT ); Mon, 4 May 2015 12:01:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43188 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751153AbbEDQA5 (ORCPT ); Mon, 4 May 2015 12:00:57 -0400 Message-ID: <55479749.7070608@redhat.com> Date: Mon, 04 May 2015 11:59:05 -0400 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Paolo Bonzini , Ingo Molnar , Andy Lutomirski CC: "linux-kernel@vger.kernel.org" , X86 ML , williams@redhat.com, Andrew Lutomirski , fweisbec@redhat.com, Peter Zijlstra , Heiko Carstens , Thomas Gleixner , Ingo Molnar , "Paul E. McKenney" , Linus Torvalds Subject: question about RCU dynticks_nesting References: <554399D1.6010405@redhat.com> <20150501155912.GA451@gmail.com> <20150501162109.GA1091@gmail.com> <5543A94B.3020108@redhat.com> <20150501163431.GB1327@gmail.com> <5543C05E.9040209@redhat.com> <20150501184025.GA2114@gmail.com> <5543CFE5.1030509@redhat.com> <20150502052733.GA9983@gmail.com> <55473B47.6080600@redhat.com> In-Reply-To: <55473B47.6080600@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/04/2015 05:26 AM, Paolo Bonzini wrote: > Isn't this racy? > > synchronize_rcu CPU nohz CPU > --------------------------------------------------------- > set flag = 0 > read flag = 0 > return to userspace > set TIF_NOHZ > > and there's no guarantee that TIF_NOHZ is ever processed by the nohz CPU. Looking at the code some more, a flag is not going to be enough. An irq can hit while we are in kernel mode, leading to the task's "rcu active" counter being incremented twice. However, currently the RCU code seems to use a much more complex counting scheme, with a different increment for kernel/task use, and irq use. This counter seems to be modeled on the task preempt_counter, where we do care about whether we are in task context, irq context, or softirq context. On the other hand, the RCU code only seems to care about whether or not a CPU is in an extended quiescent state, or is potentially in an RCU critical section. Paul, what is the reason for RCU using a complex counter, instead of a simple increment for each potential kernel/RCU entry, like rcu_read_lock() does with CONFIG_PREEMPT_RCU enabled? In fact, would we be able to simply use tsk->rcu_read_lock_nesting as an indicator of whether or not we should bother waiting on that task or CPU when doing synchronize_rcu? -- All rights reversed