Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp3512875ybg; Mon, 28 Oct 2019 14:08:25 -0700 (PDT) X-Google-Smtp-Source: APXvYqxotZaNxWGV2PmLL5zOKsPYJogJ0CF+3INBiCN9OKTMvf37C9u0qFg9pOcZRYZp9LDjkC1L X-Received: by 2002:a17:907:2139:: with SMTP id qo25mr18785960ejb.207.1572296905669; Mon, 28 Oct 2019 14:08:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572296905; cv=none; d=google.com; s=arc-20160816; b=C2GMPJBmDxvpv1UO+/ujkgtM5y8K2kwyBxDerMeK9Ytz30b6WkgPGnBwe9jsHotHXT rn4LKYXpcSGP7eF+brw6iJi7AkWFryZZ2d9bOvBBF4Yj+qF6KV9bECkSn6f/TDIC3mPw ZTEHC8HoOM2SMCTkYL34up+eJwlfgDoQ5MAG/Zqfajf6ExeoCQUO6EASNZVkjxfeypOc /eeV4dzHOJ4PkPFPxyfJkstzu1fMt8UCH/sM0LPQ81qML4OBGyBeMuF0rfNITfTOgeHI OZNChXDcbAOckGYP5MLr6p8ij+KYoQfATGW/GJzJHZ8Rd3p3aTAW1fFcZiUdaLxAo3J3 KE5Q== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=QKt787OHucNpqF4O6a1QSOGrQZYdi052tGgmHvjg1nA=; b=E2Q0TuDNUI2Q9wBYF2nJ9+BSK/aUcGuz/8R3wmXYUSyhgVqZkrv6B8MDcONKLwUdev uPjgaL1PsZzxoqAkYEhJxTVpsSGHiqmLeavSUT4rpzcaunjWIr0UlcuLfJ9om9tUe9PI K3bWqUjhBzuUyXFcpBAXCc9i+nOlXwdgzUr+ZGbCVu+HbG3q6RQNV8I1QaJm08TahhfJ WeNxANot/b7VrRY27aL0/IE+O/550IXszadhdAH9rjQs/bJ39DpAbcKyxLJndD4F975+ c5zWHE3C8S29INwFsFdjm2OkyAaccOeb/e1MP5xP3BcsxDPx3Sp0sUfuyiYqsqi+sqFq BU5Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=AFOiqgHO; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p30si7836013eda.205.2019.10.28.14.08.02; Mon, 28 Oct 2019 14:08:25 -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=@kernel.org header.s=default header.b=AFOiqgHO; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389534AbfJ1PHr (ORCPT + 99 others); Mon, 28 Oct 2019 11:07:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:46302 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726945AbfJ1PHr (ORCPT ); Mon, 28 Oct 2019 11:07:47 -0400 Received: from lenoir.home (lfbn-ncy-1-150-155.w83-194.abo.wanadoo.fr [83.194.232.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 381F621783; Mon, 28 Oct 2019 15:07:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1572275266; bh=cJMrQBmRRDz/62veZ93a0sKQIk1acNGPtdue49LiYbs=; h=From:To:Cc:Subject:Date:From; b=AFOiqgHOn4bnIA/yXpqo/OVM/Zt94fxcrVsVZNAa+Ovs2QpfFZpj3Ps5x0C5VS/RK ON9J97+O52qxT0Tq4SARIcCqNV5AwlAHh6I69cfTJAz9SQKpmrXTaN2zEWdbIc/yhI ypy5BipHf5ltz/RjxpxOFA2IcoqkbkHBcwW6+rAY= From: Frederic Weisbecker To: Thomas Gleixner , Ingo Molnar , Peter Zijlstra Cc: LKML , Scott Wood , Frederic Weisbecker Subject: [PATCH] timers/nohz: Update nohz load even if tick already stopped Date: Mon, 28 Oct 2019 16:07:16 +0100 Message-Id: <20191028150716.22890-1-frederic@kernel.org> X-Mailer: git-send-email 2.23.0 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 From: Scott Wood The way loadavg is tracked during nohz only pays attention to the load upon entering nohz. This can be particularly noticeable if nohz is entered while non-idle, and then the cpu goes idle and stays that way for a long time. We've had reports of a loadavg near 150 on a mostly idle system. Calling calc_load_nohz_start() regardless of whether the tick is already stopped addresses the issue when going idle. Tracking load changes when not going idle (e.g. multiple SCHED_FIFO tasks coming and going) is not addressed by this patch. Signed-off-by: Scott Wood Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Peter Zijlstra Signed-off-by: Frederic Weisbecker --- kernel/time/tick-sched.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c index c2748232f607..f55ddeb652a3 100644 --- a/kernel/time/tick-sched.c +++ b/kernel/time/tick-sched.c @@ -763,6 +763,9 @@ static void tick_nohz_stop_tick(struct tick_sched *ts, int cpu) ts->do_timer_last = 0; } + /* Even if the tick was already stopped, load may have changed */ + calc_load_nohz_start(); + /* Skip reprogram of event if its not changed */ if (ts->tick_stopped && (expires == ts->next_tick)) { /* Sanity check: make sure clockevent is actually programmed */ @@ -783,7 +786,6 @@ static void tick_nohz_stop_tick(struct tick_sched *ts, int cpu) * the scheduler tick in nohz_restart_sched_tick. */ if (!ts->tick_stopped) { - calc_load_nohz_start(); quiet_vmstat(); ts->last_tick = hrtimer_get_expires(&ts->sched_timer); -- 2.23.0