Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp4107913imm; Tue, 25 Sep 2018 11:27:03 -0700 (PDT) X-Google-Smtp-Source: ACcGV63j9nNP9KMRSUZ0AC4CSXkDBOjKBADXH3bpMNO+WwDnDaizXQO7GjJEEIG/5c7peTz/V0vI X-Received: by 2002:a17:902:1121:: with SMTP id d30-v6mr2293972pla.250.1537900023091; Tue, 25 Sep 2018 11:27:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537900023; cv=none; d=google.com; s=arc-20160816; b=f2cZ41IYmCwNc/Sd7znU8dpMexX2hLNyQC/ZqfQbPlsLD+rLsnNRMSWtbrlj//ELXC sNBIkZsyT5Yut2ECb9q3rglcnXDcE/MhrCIxESWea0icTPWC1aIdjXnnS/IoPgSTOpzz n33W4lWz/iOilDVdGEnPnE/js+scK33Hq1WyIkk4jBsN8iMYmFxWFgVaMxceeEygrAx4 HrjKVqXiNm4I7XZtTHG8Ma5VtuSRwslywGUptsM/ta8vgziqsx4vPvONnFnCYRqtqOdU Vetsny+Y7IkKNdVLJIr/J4A4+x5BZ2qhgoh3Q2NAIdkkKnLTGDtQVLqmWM2/gfBmu4iM ivFw== 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:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=JbXX371XcyRiCxPSWRSuCHmP9QFGA3Pa8K2HEyMazrQ=; b=rnCwbwcz6Y5ufbyUR5klatYI7PRKpyv8/5wfDs6dqEcEBMwVH3fFfee5vZMYmfQHcJ JoYrAFZ4vZJqmrKJ+3lIw8SpR2QDHCsaSQv49heRSsZ8TbSQqRvF+Utug1BVKE8wvMHT dPrOgyiDbed07YLwgE6RFlJjN52W/XeiRNv1qGrAq+ALWS8WwFIy4/Y7+Y1ZVfaEID5g R2QR8pe6ROgDLfN1XNFU6XTgEVF+yX9Xf1HPDsNhSQEB3jd9OJNtHhGdwEoC8r/xzzx5 LxRaKzr24/e12b5lklCy6q4vobhLZjavOvezHhSOZzQYBX2+NKZRTSmGIOf7JQe1kdB7 4BDQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b="n6HKD/Eb"; 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 s12-v6si2910888plp.464.2018.09.25.11.26.47; Tue, 25 Sep 2018 11:27:03 -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="n6HKD/Eb"; 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 S1727474AbeIZAfS (ORCPT + 99 others); Tue, 25 Sep 2018 20:35:18 -0400 Received: from mail-pf1-f193.google.com ([209.85.210.193]:45490 "EHLO mail-pf1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727406AbeIZAfR (ORCPT ); Tue, 25 Sep 2018 20:35:17 -0400 Received: by mail-pf1-f193.google.com with SMTP id a23-v6so4118799pfi.12 for ; Tue, 25 Sep 2018 11:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=JbXX371XcyRiCxPSWRSuCHmP9QFGA3Pa8K2HEyMazrQ=; b=n6HKD/Ebc2RqinV8HhuzA2A5V4mO0/j+jqnAjq3r5OeHJB0U6kwJIKxhsH5MCCTRcn WygmNV7Fzn5oSmmEWJ4d2RHyjNWvDjso8yD9K4W61+eWkcPo7AYWzIY+mxhufHAJOAaa 5dQRZ4qVBAOiBYd1jelliNwkcadBAjFRp3x1c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=JbXX371XcyRiCxPSWRSuCHmP9QFGA3Pa8K2HEyMazrQ=; b=pIEw3CBhIP25zMeMxYeU6wUYT/Uhh+GSiOhR3fj4MRZp2PvOIybTMcBYeKFKMpgByQ OKXFf8akcr8ofxTVQCV3KncAplBDiLf2Qfn+74IEh/KaBmHOHyU2FFlr+5lwd2ZOjPmQ nyuWskH0Egj1iuPOO4POzorVobpT1zZoK11qMKJBJBjgqBxHc0VMuOjNfBRb8BInFS/2 YiTFkJOo5Tj9r+Yk6VnkmaLqQY7BE4S2iEhLdZt/OvCGPZVY82xV12hz1GsHFRq1zsIf D/FJyMtlvhrC7jBMln35/3++1NzpV2UaxcZxr/MaIiOeGu9akSSwifZ/M0vfXMEc39mI 9Aow== X-Gm-Message-State: ABuFfoin+nkAfVXOJq0N9eswBWqqwzTR9dJfpeuHVt3Wl3sbFhNs1/mT Oxs90/ONOJGrOa0vOCFpOe7aJwxXlMM= X-Received: by 2002:a63:d645:: with SMTP id d5-v6mr2162444pgj.450.1537899988723; Tue, 25 Sep 2018 11:26:28 -0700 (PDT) Received: from joelaf-glaptop0.roam.corp.google.com (c-98-210-118-128.hsd1.ca.comcast.net. [98.210.118.128]) by smtp.gmail.com with ESMTPSA id x70-v6sm6883626pfk.85.2018.09.25.11.26.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Sep 2018 11:26:27 -0700 (PDT) From: "Joel Fernandes (Google)" To: linux-kernel@vger.kernel.org Cc: "Joel Fernandes (Google)" , Jonathan Corbet , Josh Triplett , Lai Jiangshan , linux-doc@vger.kernel.org, Mathieu Desnoyers , "Paul E. McKenney" , Steven Rostedt Subject: [2/5] doc: rcu: Remove rcu_dynticks from Data-Structures Date: Tue, 25 Sep 2018 11:25:58 -0700 Message-Id: <20180925182601.37421-3-joel@joelfernandes.org> X-Mailer: git-send-email 2.19.0.444.g18242da7ef-goog In-Reply-To: <20180925182601.37421-1-joel@joelfernandes.org> References: <20180925182601.37421-1-joel@joelfernandes.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org rcu_dynticks was folded into rcu_data structure. Update the data structures RCU document accordingly. Signed-off-by: Joel Fernandes (Google) --- .../BigTreeClassicRCUBHdyntick.svg | 695 ------------------ .../Data-Structures/Data-Structures.html | 92 +-- 2 files changed, 25 insertions(+), 762 deletions(-) delete mode 100644 Documentation/RCU/Design/Data-Structures/BigTreeClassicRCUBHdyntick.svg diff --git a/Documentation/RCU/Design/Data-Structures/BigTreeClassicRCUBHdyntick.svg b/Documentation/RCU/Design/Data-Structures/BigTreeClassicRCUBHdyntick.svg deleted file mode 100644 index 21ba7823479d..000000000000 --- a/Documentation/RCU/Design/Data-Structures/BigTreeClassicRCUBHdyntick.svg +++ /dev/null @@ -1,695 +0,0 @@ - - - - - - - - - - - - image/svg+xml - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - rcu_bh - - struct - - rcu_node - - struct - - rcu_node - - rcu_node - - struct - - struct - - rcu_data - - struct - - rcu_data - - struct - - rcu_data - - struct - - rcu_data - - struct rcu_state - - struct - - rcu_dynticks - - struct - - rcu_dynticks - - struct - - rcu_dynticks - - struct - - rcu_dynticks - - rcu_sched - - - - - diff --git a/Documentation/RCU/Design/Data-Structures/Data-Structures.html b/Documentation/RCU/Design/Data-Structures/Data-Structures.html index 476b1ac38e4c..f58cd3912918 100644 --- a/Documentation/RCU/Design/Data-Structures/Data-Structures.html +++ b/Documentation/RCU/Design/Data-Structures/Data-Structures.html @@ -23,8 +23,6 @@ to each other. The rcu_segcblist Structure
  • The rcu_data Structure -
  • - The rcu_dynticks Structure
  • The rcu_head Structure
  • @@ -173,17 +171,9 @@ CPUs whose scheduling-clock interrupts have been turned off are said to be in dyntick-idle mode. RCU must handle dyntick-idle CPUs specially because RCU would otherwise wake up each CPU on every grace period, -which would defeat the whole purpose of CONFIG_NO_HZ_IDLE. -RCU uses the rcu_dynticks structure to track -which CPUs are in dyntick idle mode, as shown below: - -

    BigTreeClassicRCUBHdyntick.svg - -

    However, if a CPU is in dyntick-idle mode, it is in that mode -for all flavors of RCU. -Therefore, a single rcu_dynticks structure is allocated per -CPU, and all of a given CPU's rcu_data structures share -that rcu_dynticks, as shown in the figure. +which would defeat the whole purpose of CONFIG_NO_HZ_IDLE. RCU uses +the dynticks related fields in the rcu_data structure to track which +CPUs are in dyntick idle mode.

    Kernels built with CONFIG_PREEMPT_RCU support rcu_preempt in addition to rcu_sched and rcu_bh, as shown below: @@ -216,9 +206,6 @@ its own synchronization:

  • Each rcu_node structure has a spinlock.
  • The fields in rcu_data are private to the corresponding CPU, although a few can be read and written by other CPUs. -
  • Similarly, the fields in rcu_dynticks are private - to the corresponding CPU, although a few can be read by - other CPUs.

    It is important to note that different data structures can have @@ -274,11 +261,6 @@ follows: access to this information from the corresponding CPU. Finally, this structure records past dyntick-idle state for the corresponding CPU and also tracks statistics. -

  • rcu_dynticks: - This per-CPU structure tracks the current dyntick-idle - state for the corresponding CPU. - Unlike the other three structures, the rcu_dynticks - structure is not replicated per RCU flavor.
  • rcu_head: This structure represents RCU callbacks, and is the only structure allocated and managed by RCU users. @@ -289,8 +271,8 @@ follows:

    If all you wanted from this article was a general notion of how RCU's data structures are related, you are done. Otherwise, each of the following sections give more details on -the rcu_state, rcu_node, rcu_data, -and rcu_dynticks data structures. +the rcu_state, rcu_node and rcu_data data +structures.

    The rcu_state Structure

    @@ -1017,30 +999,18 @@ as follows: 
       1   int cpu;
-  2   struct rcu_state *rsp;
-  3   struct rcu_node *mynode;
-  4   struct rcu_dynticks *dynticks;
-  5   unsigned long grpmask;
-  6   bool beenonline;
+  2   struct rcu_node *mynode;
+  3   unsigned long grpmask;
+  4   bool beenonline;

    The ->cpu field contains the number of the -corresponding CPU, the ->rsp pointer references -the corresponding rcu_state structure (and is most frequently -used to locate the name of the corresponding flavor of RCU for tracing), -and the ->mynode field references the corresponding -rcu_node structure. +corresponding CPU and the ->mynode field references the +corresponding rcu_node structure. The ->mynode is used to propagate quiescent states up the combining tree. -

    The ->dynticks pointer references the -rcu_dynticks structure corresponding to this -CPU. -Recall that a single per-CPU instance of the rcu_dynticks -structure is shared among all flavors of RCU. -These first four fields are constant and therefore require not -synchronization. - -

    The ->grpmask field indicates the bit in +These two fields are constant and therefore donot require synchronization. +

    The ->grpmask field indicates the bit in the ->mynode->qsmask corresponding to this rcu_data structure, and is also used when propagating quiescent states. @@ -1181,26 +1151,22 @@ Finally, the ->dynticks_fqs field is used to count the number of times this CPU is determined to be in dyntick-idle state, and is used for tracing and debugging purposes. -

    -The rcu_dynticks Structure

    - -

    The rcu_dynticks maintains the per-CPU dyntick-idle state -for the corresponding CPU. -Unlike the other structures, rcu_dynticks is not -replicated over the different flavors of RCU. -The fields in this structure may be accessed only from the corresponding -CPU (and from tracing) unless otherwise stated. -Its fields are as follows: +

    +This portion of the rcu_data structure is declared as follows: 

       1   long dynticks_nesting;
   2   long dynticks_nmi_nesting;
   3   atomic_t dynticks;
   4   bool rcu_need_heavy_qs;
-  5   unsigned long rcu_qs_ctr;
-  6   bool rcu_urgent_qs;
+  5   bool rcu_urgent_qs;
    +

    These fields in the rcu_data structure maintain the per-CPU dyntick-idle +state for the corresponding CPU. +The fields may be accessed only from the corresponding CPU (and from tracing) +unless otherwise stated. +

    The ->dynticks_nesting field counts the nesting depth of process execution, so that in normal circumstances this counter has value zero or one. @@ -1242,19 +1208,11 @@ it is willing to call for heavy-weight dyntick-counter operations. This flag is checked by RCU's context-switch and cond_resched() code, which provide a momentary idle sojourn in response. -

    The ->rcu_qs_ctr field is used to record -quiescent states from cond_resched(). -Because cond_resched() can execute quite frequently, this -must be quite lightweight, as in a non-atomic increment of this -per-CPU field. -

    Finally, the ->rcu_urgent_qs field is used to record -the fact that the RCU core code would really like to see a quiescent -state from the corresponding CPU, with the various other fields indicating -just how badly RCU wants this quiescent state. -This flag is checked by RCU's context-switch and cond_resched() -code, which, if nothing else, non-atomically increment ->rcu_qs_ctr -in response. +the fact that the RCU core code would really like to see a quiescent state from +the corresponding CPU, with the various other fields indicating just how badly +RCU wants this quiescent state. This flag is checked by RCU's context-switch path +(rcu_note_context_switch) and the cond_resched code. @@ -1431,7 +1389,7 @@ So each flavor of RCU is represented by an rcu_state structure, which contains a combining tree of rcu_node and rcu_data structures. Finally, in CONFIG_NO_HZ_IDLE kernels, each CPU's dyntick-idle -state is tracked by an rcu_dynticks structure. +state is tracked by dynticks-related fields in the rcu_data structure. If you made it this far, you are well prepared to read the code walkthroughs in the other articles in this series. -- 2.19.0.444.g18242da7ef-goog