From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 379D7C0650E for ; Thu, 4 Jul 2019 04:34:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0AD8E2189E for ; Thu, 4 Jul 2019 04:34:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=joelfernandes.org header.i=@joelfernandes.org header.b="vSdua536" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726038AbfGDEej (ORCPT ); Thu, 4 Jul 2019 00:34:39 -0400 Received: from mail-pl1-f194.google.com ([209.85.214.194]:35666 "EHLO mail-pl1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725920AbfGDEej (ORCPT ); Thu, 4 Jul 2019 00:34:39 -0400 Received: by mail-pl1-f194.google.com with SMTP id w24so2388513plp.2 for ; Wed, 03 Jul 2019 21:34:39 -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:mime-version :content-transfer-encoding; bh=7vbppYg/PV/7L5iaCilqYrS88KLuUxXV/tcBcygZ/DM=; b=vSdua536NKvlq/muYod+Jq39qhq9nRhECF2mZYOuyu5lZpriRV/S6tJYaf/Pw9PHZ/ lZfpE7zfIuF/+6bGXZkeMn8jkyGBSRQMOOuZUffJGlRZL7Gou+fT1Ojz7VI/nnFKiI7m F5/Cov48q5JztOsOlW9D0/vvuOiRNNPKCdDC8= 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:mime-version :content-transfer-encoding; bh=7vbppYg/PV/7L5iaCilqYrS88KLuUxXV/tcBcygZ/DM=; b=eRv8THCjEqVASzu8QKa5WUhxPtwnqPQTo3/5l9Wz3fF6yg3XK+QcVZhqgFhe9i1zsL OQXCsQQWVo1JrB/rHC3LHjWYaYI76JfMYkc/KfZ4dk1mboFnhwRghmEmZ8+v4qIA2lMw 8e2hmDsi/oHyfh8SkzPZ0GkbBXpk68GxaRxDRB3ZcBYL1WQzA40Bg9MlhaWedTZK4ZxP 8CrP+RY3cInxi16tdC9mN955v4dmHplh83nqGBGsaE8piYa9Bw1wCiDAMCyl6xzfLAUH wWfJXeJQyA24HOzoYvHT3iKcYTfaXG6jc2A5Oy/AyVRcpi/SryOhgFepdnkEYQKPx6AA +Mdw== X-Gm-Message-State: APjAAAVAM68m6Jm5KNBGzp82lpO8gKVM/TE+xt6zYMQH0pAE3ZELJR5i h/ylZyvXOmHuSArd4KYD88KcjA== X-Google-Smtp-Source: APXvYqwVb4pSb+wRU1yNknNpnD1K4ghm+jlabCGwIkOi0NNnKD1g3x6RkZi6gHlb7LQd044e3blFGg== X-Received: by 2002:a17:902:a504:: with SMTP id s4mr32822885plq.117.1562214878674; Wed, 03 Jul 2019 21:34:38 -0700 (PDT) Received: from joelaf.cam.corp.google.com ([2620:15c:6:12:9c46:e0da:efbf:69cc]) by smtp.gmail.com with ESMTPSA id b24sm3837621pfd.98.2019.07.03.21.34.36 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 03 Jul 2019 21:34:37 -0700 (PDT) From: "Joel Fernandes (Google)" To: linux-kernel@vger.kernel.org Cc: "Joel Fernandes (Google)" , Davidlohr Bueso , Josh Triplett , Lai Jiangshan , Mathieu Desnoyers , "Paul E. McKenney" , rcu@vger.kernel.org, Steven Rostedt , kernel-team@android.com Subject: [PATCH] rcuperf: Make rcuperf kernel test more robust for !expedited mode Date: Thu, 4 Jul 2019 00:34:30 -0400 Message-Id: <20190704043431.208689-1-joel@joelfernandes.org> X-Mailer: git-send-email 2.22.0.410.gd8fdbe21b5-goog MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: rcu-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: rcu@vger.kernel.org It is possible that the rcuperf kernel test runs concurrently with init starting up. During this time, the system is running all grace periods as expedited. However, rcuperf can also be run for normal GP tests. Right now, it depends on a holdoff time before starting the test to ensure grace periods start later. This works fine with the default holdoff time however it is not robust in situations where init takes greater than the holdoff time to finish running. Or, as in my case: I modified the rcuperf test locally to also run a thread that did preempt disable/enable in a loop. This had the effect of slowing down init. The end result was that the "batches:" counter in rcuperf was 0 causing a division by 0 error in the results. This counter was 0 because only expedited GPs seem to happen, not normal ones which led to the rcu_state.gp_seq counter remaining constant across grace periods which unexpectedly happen to be expedited. The system was running expedited RCU all the time because rcu_unexpedited_gp() would not have run yet from init. In other words, the test would concurrently with init booting in expedited GP mode. To fix this properly, let us check if system_state if SYSTEM_RUNNING is set before starting the test. The system_state approximately aligns with when rcu_unexpedited_gp() is called and works well in practice. I also tried late_initcall however it is still too early to be meaningful for this case. Signed-off-by: Joel Fernandes (Google) --- kernel/rcu/rcuperf.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/kernel/rcu/rcuperf.c b/kernel/rcu/rcuperf.c index 4513807cd4c4..5a879d073c1c 100644 --- a/kernel/rcu/rcuperf.c +++ b/kernel/rcu/rcuperf.c @@ -375,6 +375,14 @@ rcu_perf_writer(void *arg) if (holdoff) schedule_timeout_uninterruptible(holdoff * HZ); + /* + * Wait until rcu_end_inkernel_boot() is called for normal GP tests + * so that RCU is not always expedited for normal GP tests. + * The system_state test is approximate, but works well in practice. + */ + while (!gp_exp && system_state != SYSTEM_RUNNING) + schedule_timeout_uninterruptible(1); + t = ktime_get_mono_fast_ns(); if (atomic_inc_return(&n_rcu_perf_writer_started) >= nrealwriters) { t_rcu_perf_writer_started = t; -- 2.22.0.410.gd8fdbe21b5-goog