Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp4656549imm; Mon, 14 May 2018 10:39:38 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoezvdU8MvjNVHv5zi27VGYZVcsq0UIaNaCe90dF9tamWQYr93vrUxcXZn2aYzs/VBk+e6M X-Received: by 2002:a17:902:850a:: with SMTP id bj10-v6mr10605574plb.239.1526319578065; Mon, 14 May 2018 10:39:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526319578; cv=none; d=google.com; s=arc-20160816; b=D/HVnQD5EmspcJ6Gk8uovFE8dKhUo3PODIskDW/7DHWmAEuLio5ZOQZHDtT92br4Hh 0K2IrNA1ZELI8BOOHl/UpxV28XrkXzaB6K9ikFMERmP3YD3JsqSzOATEVX9KJbWyhN3W 8AgGy9Hp9yYpPBFXJvLJY0xhMpx+9huw/GU61VjHpfajnEBsZJaAvK/9QH4tssZICQJu /rkz6UheO2BhaYpwIm4cSmIRqiZoaWS3XzqKMh9lTzses6TyeHxUA8xBz9S14xJyq1DB 9Z/ZOOrXMFC4uRKeiN2Ju9t1M1NBSimIrsRwrLXPYtxS4wDLIBSixhH0d/1bRcYGL5YY FRTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:user-agent:in-reply-to :content-disposition:mime-version:references:reply-to:subject:cc:to :from:date:arc-authentication-results; bh=cZBY68ZGR5c61qh+7EIoOv++V81Vc9scpJlfPGzvd+k=; b=ADP0XweWgQprFb1iGHg2V9/XD3A99l8YcgAJno+sk5CF8s8OCR1tkyMqxAzbBN2QJS fQtrltmwltJEP/cWIAtdqGUXEz8+NMHfd3+0S8kQYdRYao9ofDOEJHz4C4HiAgt8ry1R J8nI6uR0HUl8yVTn/TtFqQOyr6umQNMI9DEAT3QXvKLT/i0WMd07yP11E8Z5gzXtWIYn aOMeI2Ym+pqwro1a5M72nfjdi2CA+PvR930Az7fNiCJgNfK0cvPpE7sbpVY73RzBsAR+ dw1SF4YFMKXdejiSlVj0wE8tRAbl+VQEAEKEnxikrPWckxETCarT3MvW0S7ozFN3aSH1 AYNg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u10-v6si9521848pfn.44.2018.05.14.10.39.23; Mon, 14 May 2018 10:39:37 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752441AbeENRUu (ORCPT + 99 others); Mon, 14 May 2018 13:20:50 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:59896 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752292AbeENRUk (ORCPT ); Mon, 14 May 2018 13:20:40 -0400 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4EHDsfm035135 for ; Mon, 14 May 2018 13:20:39 -0400 Received: from e12.ny.us.ibm.com (e12.ny.us.ibm.com [129.33.205.202]) by mx0a-001b2d01.pphosted.com with ESMTP id 2hydx7j4de-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 14 May 2018 13:20:39 -0400 Received: from localhost by e12.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 14 May 2018 13:20:38 -0400 Received: from b01cxnp22034.gho.pok.ibm.com (9.57.198.24) by e12.ny.us.ibm.com (146.89.104.199) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 14 May 2018 13:20:35 -0400 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b01cxnp22034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w4EHKYfb51118132; Mon, 14 May 2018 17:20:34 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B5895B2046; Mon, 14 May 2018 14:22:32 -0400 (EDT) Received: from paulmck-ThinkPad-W541 (unknown [9.70.82.108]) by b01ledav003.gho.pok.ibm.com (Postfix) with ESMTP id 7E242B204E; Mon, 14 May 2018 14:22:32 -0400 (EDT) Received: by paulmck-ThinkPad-W541 (Postfix, from userid 1000) id EC56E16C2301; Mon, 14 May 2018 10:22:05 -0700 (PDT) Date: Mon, 14 May 2018 10:22:05 -0700 From: "Paul E. McKenney" To: Steven Rostedt Cc: "Joel Fernandes (Google)" , linux-kernel@vger.kernel.org, Josh Triplett , Mathieu Desnoyers , Lai Jiangshan , byungchul.park@lge.com, kernel-team@android.com Subject: Re: [PATCH RFC 2/8] rcu: Clarify usage of cond_resched for tasks-RCU Reply-To: paulmck@linux.vnet.ibm.com References: <20180514031541.67247-1-joel@joelfernandes.org> <20180514031541.67247-3-joel@joelfernandes.org> <20180514105454.45946ad3@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180514105454.45946ad3@gandalf.local.home> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 18051417-0048-0000-0000-0000026CD55E X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00009025; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000260; SDB=6.01032259; UDB=6.00527710; IPR=6.00811391; MB=3.00021110; MTD=3.00000008; XFM=3.00000015; UTC=2018-05-14 17:20:37 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18051417-0049-0000-0000-0000451E79C8 Message-Id: <20180514172205.GZ26088@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-14_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1805140174 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 14, 2018 at 10:54:54AM -0400, Steven Rostedt wrote: > On Sun, 13 May 2018 20:15:35 -0700 > "Joel Fernandes (Google)" wrote: > > > Recently we had a discussion about cond_resched unconditionally > > recording a voluntary context switch [1]. > > > > Lets add a comment clarifying that how this API is to be used. > > > > [1] https://lkml.kernel.org/r/1526027434-21237-1-git-send-email-byungchul.park@lge.com > > > > Signed-off-by: Joel Fernandes (Google) > > --- > > include/linux/rcupdate.h | 11 ++++++++--- > > 1 file changed, 8 insertions(+), 3 deletions(-) > > > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h > > index 743226176350..a9881007ece6 100644 > > --- a/include/linux/rcupdate.h > > +++ b/include/linux/rcupdate.h > > @@ -159,8 +159,12 @@ static inline void rcu_init_nohz(void) { } > > } while (0) > > > > /* > > - * Note a voluntary context switch for RCU-tasks benefit. This is a > > - * macro rather than an inline function to avoid #include hell. > > + * Note an attempt to perform a voluntary context switch for RCU-tasks benefit. > > + * > > + * This is called even in situations where a context switch didn't really > > + * happen even though it was requested. The caller uses it to indicate > > + * traversal of an RCU-tasks quiescent state. This is a macro rather than an > > + * inline function to avoid #include hell. > > I don't know. I just don't like the wording. It sounds too much like > it was written by someone that was confused for it being called when a > context switch didn't occur ;-) > > What about something more like: > > /* > * This is called to denote a RCU-task quiescent state. It is placed at > * voluntary preemption points, as RCU-task critical sections may not > * perform voluntary preemption or scheduling calls. It does not matter > * if the task is scheduled out or not, just that a voluntary preemption > * may be done. > */ s/RCU-task/RCU-tasks/ and I am good with this. Thanx, Paul > > */ > > #ifdef CONFIG_TASKS_RCU > > #define rcu_note_voluntary_context_switch_lite(t) \ > > @@ -187,7 +191,8 @@ static inline void exit_tasks_rcu_finish(void) { } > > #endif /* #else #ifdef CONFIG_TASKS_RCU */ > > > > /** > > - * cond_resched_tasks_rcu_qs - Report potential quiescent states to RCU > > + * cond_resched_tasks_rcu_qs - Report potential quiescent states to RCU. > > + * The quiescent state report is made even if cond_resched() did nothing. > > Same thing here. > > * The quiescent state report does not depend on cond_resched() scheduling. > > -- Steve > > > > * > > * This macro resembles cond_resched(), except that it is defined to > > * report potential quiescent states to RCU-tasks even if the cond_resched() >