Received: by 10.223.185.116 with SMTP id b49csp4672836wrg; Tue, 6 Mar 2018 21:56:53 -0800 (PST) X-Google-Smtp-Source: AG47ELtqB1VKw81IrtWMff08wMP3zzOIx/FZQL494wwidUwJoCmHpBFowzDWctOysP7OFe64B8OJ X-Received: by 2002:a17:902:9009:: with SMTP id a9-v6mr18802951plp.272.1520402213284; Tue, 06 Mar 2018 21:56:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520402213; cv=none; d=google.com; s=arc-20160816; b=To+AKsTFA8QQvvwc14zmg8630okVMhR3cL9DxlM39ujjqmotpujTm8bhvd82kphq2R XS7XylYi2hRdfzzj7/8iBxqxyQi5GtBxU1+6LYVHSwR+GfPVDhzkgVOIfojKJcQpDIjT wMj+3PKcquJ1kIyN4GzGdHkC4Mki6SW4T7rvWOCVyvrmaeSMPWA8lEZ9cIB9JETItZam 9yOOJM2c5Fjebq4Eaafqhg9lw0hOzHyQ36vWGwa+p9fcMgJNx12GNBs0GkED2zm13Pix WI6FDWFGxccalPI9WE8Jh7aIpn313GL3m4ijMC0zNH5gXqmEIyrHOX/hGb7axwOz9inn wyaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=Vs28ee8WPEXSrowl1+mUY87b8hFhFpljV85+S4z/TxY=; b=0CODGaT1HdFJQ52gFZk5imo+mS6fHfyiZmPV9t1uv5rb2FMT63gfLwvNyam3JJAGuH 00B3O65Us/bm0vf6eABqGb3U6hpnYj6evuEUKlaTM9nI0XpMtDzXx3uYI/1ZjTFaNa/5 FyWT6WsKWn8KFp9LnE+UgYJIxqm8dl6CJ/hDV+EHFgRD3GX+oVnlOzQSLDC5aqqj6uGK QjVRAqGG/LVsagpr4r1AI72QkrD30w3WOAde4yRPMFDEqnUswyr3rSRzZXWsuGtOmWyp RW9Y1htxwgKTvQN1bJ/nuToqjHPqbOuH+YqXCv6L5OnupAqQp9GRop9q6pbKGMdf8dUf hm/A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a3-v6si12341385plp.76.2018.03.06.21.56.38; Tue, 06 Mar 2018 21:56:53 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751109AbeCGFzp (ORCPT + 99 others); Wed, 7 Mar 2018 00:55:45 -0500 Received: from LGEAMRELO13.lge.com ([156.147.23.53]:53806 "EHLO lgeamrelo13.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750977AbeCGFzo (ORCPT ); Wed, 7 Mar 2018 00:55:44 -0500 Received: from unknown (HELO lgemrelse7q.lge.com) (156.147.1.151) by 156.147.23.53 with ESMTP; 7 Mar 2018 14:55:42 +0900 X-Original-SENDERIP: 156.147.1.151 X-Original-MAILFROM: byungchul.park@lge.com Received: from unknown (HELO ?10.177.222.184?) (10.177.222.184) by 156.147.1.151 with ESMTP; 7 Mar 2018 14:55:41 +0900 X-Original-SENDERIP: 10.177.222.184 X-Original-MAILFROM: byungchul.park@lge.com Subject: Re: [RFC] rcu: Prevent expedite reporting within RCU read-side section To: Boqun Feng Cc: jiangshanlai@gmail.com, paulmck@linux.vnet.ibm.com, josh@joshtriplett.org, rostedt@goodmis.org, mathieu.desnoyers@efficios.com, linux-kernel@vger.kernel.org, kernel-team@lge.com References: <1520314318-30916-1-git-send-email-byungchul.park@lge.com> <20180306134205.lwmn3cgisnwkngcf@tardis> From: Byungchul Park Message-ID: <908c33f9-c8ed-5d4e-91cb-a123de5dbbc7@lge.com> Date: Wed, 7 Mar 2018 14:55:40 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180306134205.lwmn3cgisnwkngcf@tardis> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/6/2018 10:42 PM, Boqun Feng wrote: > On Tue, Mar 06, 2018 at 02:31:58PM +0900, Byungchul Park wrote: >> Hello Paul and RCU folks, >> >> I am afraid I correctly understand and fix it. But I really wonder why >> sync_rcu_exp_handler() reports the quiescent state even in the case that >> current task is within a RCU read-side section. Do I miss something? >> >> If I correctly understand it and you agree with it, I can add more logic >> which make it more expedited by boosting current or making it urgent >> when we fail to report the quiescent state on the IPI. >> >> ----->8----- >> From 0b0191f506c19ce331a1fdb7c2c5a00fb23fbcf2 Mon Sep 17 00:00:00 2001 >> From: Byungchul Park >> Date: Tue, 6 Mar 2018 13:54:41 +0900 >> Subject: [RFC] rcu: Prevent expedite reporting within RCU read-side section >> >> We report the quiescent state for this cpu if it's out of RCU read-side >> section at the moment IPI was just fired during the expedite process. >> >> However, current code reports the quiescent state even in the case: >> >> 1) the current task is still within a RCU read-side section >> 2) the current task has been blocked within the RCU read-side section >> > > If this happens, the task will queue itself in > rcu_preempt_note_context_switch() using rcu_preempt_ctxt_queue(). The gp > kthread will wait for this task to dequeue itself. IOW, we have other > mechanism to wait for this task other than bottom-up qs reporting tree. > So I think we are fine here. Right. Basically we consider both the quiscent state within the current task and queued tasks on rcu nodes that you mentioned, to control grace periods when PREEMPT kernel is used. Actually my concern was if it's safe to clear the bit of 'expmask' on the IPI for all possible cases, even though anyway blocked tasks would try to prevent the grace period from ending. I worried if something subtle might cause problems, but the code looks fine on second thought as you said. Thank you for your explanation. > Regards, > Boqun > >> Since we don't get to the quiescent state yet in the case, we shouldn't >> report it but check it another time. >> >> Signed-off-by: Byungchul Park >> --- >> kernel/rcu/tree_exp.h | 12 ++++++------ >> 1 file changed, 6 insertions(+), 6 deletions(-) >> >> diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h >> index 73e1d3d..cc69d14 100644 >> --- a/kernel/rcu/tree_exp.h >> +++ b/kernel/rcu/tree_exp.h >> @@ -731,13 +731,13 @@ static void sync_rcu_exp_handler(void *info) >> /* >> * We are either exiting an RCU read-side critical section (negative >> * values of t->rcu_read_lock_nesting) or are not in one at all >> - * (zero value of t->rcu_read_lock_nesting). Or we are in an RCU >> - * read-side critical section that blocked before this expedited >> - * grace period started. Either way, we can immediately report >> - * the quiescent state. >> + * (zero value of t->rcu_read_lock_nesting). We can immediately >> + * report the quiescent state. >> */ >> - rdp = this_cpu_ptr(rsp->rda); >> - rcu_report_exp_rdp(rsp, rdp, true); >> + if (t->rcu_read_lock_nesting <= 0) { >> + rdp = this_cpu_ptr(rsp->rda); >> + rcu_report_exp_rdp(rsp, rdp, true); >> + } >> } >> >> /** >> -- >> 1.9.1 >> -- Thanks, Byungchul