Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp2975671ybh; Mon, 16 Mar 2020 13:19:53 -0700 (PDT) X-Google-Smtp-Source: ADFU+vt89wsjcyXiggePc+55is0GQQD6rlYC128Sd498wqW8XaL1acR82h2b3t8wDrOnNH+VORoG X-Received: by 2002:aca:f0d7:: with SMTP id o206mr917728oih.41.1584389992919; Mon, 16 Mar 2020 13:19:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584389992; cv=none; d=google.com; s=arc-20160816; b=QRWBrW67oDQpza9lHesL+w+Io710RC9y2M3qtfXJjkDoGBss2x7ovQxdZmL8UJieoN zwqmoD1XfHtPG+vi1KfSOcisjMzm3pAXyMbhxq7kL1cX5erLuzzm0+thL3rSgJJ2p7Df 06A9nwF89lrO5cdSPWAZcwPxXJmhqDr5KbyOffSfHxStL4uE7yQHLs16c2hlkg/5RBjF sROmmq+TjFwHTVPXoMUAQDBVhxviv1AWEkyzIp57AV48oF9PfwOD/Jq6tQuI3MwU68Yv zHMlKdanHV/7DyHJZIGheZcihD1/zIcs17Syz+x/WEBwETPmCIhG04LqgJHPeURFvKjy KTxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Y4LE69CtgmHSa6+ujtK+0FhmSJ81UdxYmv4ZawIVShQ=; b=TeDtX/5kRYiB2WIX/xbVUFjdlFoaFZeBSPjEKUxObmxwWgmzwJxfuVl+KmMIWGntCM MCAAPlw/NQ1a3Jnh71AfE26sQYxkgG+eAjCORserlbAdC/P2YHyijDVcyG6jQPbZaTfW 4WKBucObWBKiLiwrlKVVyXZvzbpT2pfOPuvsqbwFtKp/2OhWlFq+tjIgsM7Tk/cNaZNh HQudVR6Lq+uwZDXPphHws+HI18qe9LYf87l9VUKdrEIXFmN29FRmoTbWh0tgT835BWKD g3n7bcVbm9mnGCBk3mA4aqE22etD+3W21uXQWtTK5ILBQOGgF/kLXatCJqqlSBsVTX+u ljFQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=VG07PfzC; 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 l21si441998otq.144.2020.03.16.13.19.39; Mon, 16 Mar 2020 13:19:52 -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; dkim=pass header.i=@joelfernandes.org header.s=google header.b=VG07PfzC; 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 S1732535AbgCPUSF (ORCPT + 99 others); Mon, 16 Mar 2020 16:18:05 -0400 Received: from mail-il1-f194.google.com ([209.85.166.194]:40242 "EHLO mail-il1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732467AbgCPUSE (ORCPT ); Mon, 16 Mar 2020 16:18:04 -0400 Received: by mail-il1-f194.google.com with SMTP id p12so3195960ilm.7 for ; Mon, 16 Mar 2020 13:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y4LE69CtgmHSa6+ujtK+0FhmSJ81UdxYmv4ZawIVShQ=; b=VG07PfzCoXZaY28uW8BV7Y3nOHaSbqzz/9XQN7J6vP6qShNjz/QNiUqmhsEEOHV7Hu Vyusdy+r17T/7fL7QeaUDnZVAMpL2ab3dVHBPz03z93l6POEAca/Qm2n6fQJtOPAwEm/ n4sBnhSjql19s679ntzoCd7F8n9eKAkt0vssY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y4LE69CtgmHSa6+ujtK+0FhmSJ81UdxYmv4ZawIVShQ=; b=jUf1hTjJ4tduBGOu1lNCInNWVz4BcV344LH69xjkQJ4Ei5D1XwnWDycLTt0N8h+ah9 EgCMWnY33wsnqsb7sKSfgLH+kO6GCwFHXsxqwzgIYmeLM/+/IahzAbz0+OIzNmaB60ts dYWpLCH5Gl5nq26OJyjoSCgAeRd5z+NP6NI63pebtEEpKYdtK5dsR3Tda2OlfnxpPfqo SFgAg38UTyXAg2JaTSxpg0W3jrAxllpwk3jq/2CZuomyoz9fTA7iEWM5QicsDljuOoIK w/Wf3w26C5vbewy5RVpz+Ww/KPpDubrQ7TGvKg24FvS0WXGPode0sklgzRu0q5pPnOJR OFkw== X-Gm-Message-State: ANhLgQ08JpVSitsY8OvYM0mZtLFCEiuiOj27RUdir+Y5CSegI9BqI8PF BHU7xcp9yvYFiaC1wI8UE1dJ2yLF5l3NDw/8O3lFfw== X-Received: by 2002:a92:1e0e:: with SMTP id e14mr1659768ile.13.1584389882356; Mon, 16 Mar 2020 13:18:02 -0700 (PDT) MIME-Version: 1.0 References: <20200312181618.GA21271@paulmck-ThinkPad-P72> <20200312181702.8443-9-paulmck@kernel.org> <20200316194754.GA172196@google.com> In-Reply-To: <20200316194754.GA172196@google.com> From: Joel Fernandes Date: Mon, 16 Mar 2020 16:17:51 -0400 Message-ID: Subject: Re: [PATCH RFC tip/core/rcu 09/16] rcu-tasks: Add an RCU-tasks rude variant To: "Paul E. McKenney" Cc: rcu , LKML , "kernel-team@fb.com," , Ingo Molnar , Lai Jiangshan , dipankar , Andrew Morton , Mathieu Desnoyers , Josh Triplett , Thomas Glexiner , Peter Zijlstra , Steven Rostedt , David Howells , Eric Dumazet , Frederic Weisbecker , Oleg Nesterov Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 16, 2020 at 3:47 PM Joel Fernandes wrote: > > On Thu, Mar 12, 2020 at 11:16:55AM -0700, paulmck@kernel.org wrote: > > From: "Paul E. McKenney" > > > > This commit adds a "rude" variant of RCU-tasks that has as quiescent > > states schedule(), cond_resched_tasks_rcu_qs(), userspace execution, > > and (in theory, anyway) cond_resched(). Updates make use of IPIs and > > force an IPI and a context switch on each online CPU. This variant > > is useful in some situations in tracing. > > Would it be possible to better clarify that the "rude version" works only > from preempt-disabled regions? Is that also true for the "non-rude" version? > > Also it would be good to clarify better in cover letter, how these new > flavors relate to the existing Tasks-RCU implementation. > > In the existing one, a quiescent state is a task updating its context switch > counters such that it went to sleep at least once, implying there is no > chance it is on an about to be destroyed trampoline. > > However, here we are trying to determine if a task state is no longer on an > RQ (which I gleaned from the first patch). Sounds very similar, would the > context switch counters not help in that determination as well? If it is Ok, > it would be good to describe in cover letter about what is exactly is a > quiescent state and what exactly is a reader section in the cover letter, for > both non-rude and rude version. Thanks! Just curious, why is the "rude" version better than SRCU? Seems the schedule_on_each_cpu() would be much slower than SRCU especially if there are 1000s of CPUs involved. Is there any reason that is a better alternative? thanks, - Joel