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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 682AFCDB474 for ; Fri, 20 Oct 2023 08:02:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376491AbjJTICN (ORCPT ); Fri, 20 Oct 2023 04:02:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53400 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376472AbjJTICG (ORCPT ); Fri, 20 Oct 2023 04:02:06 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D6AC6D64; Fri, 20 Oct 2023 01:02:03 -0700 (PDT) Date: Fri, 20 Oct 2023 08:02:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1697788921; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AVM/DO9hPX/HC+aIcLv1OaWWQdOPuPcK8XTJEhv9K68=; b=YQgefFkcxhKEHvHDQmIVENrY61IH4mKpcdpRizRCQh0YE7mZvYHsD1+GMY2jiW74XTBtSh rcG4U2OzRF39XRFZ0JpBn2TcHGdPSfyYwnhhpC3q6OSqsxl8Le2EaI65OvN7/fhWx/HQ36 tFZCBrLpRX2LF0OwSNz04fv3g0L01aTFmQcaIB0RfGSmmXGycklW/URGZ0JMGbWhWdWsHb 3mf6hJsxnXm7K3/6YF5OAnBppJOvn/2wE2yz8W/+9ps3Fe9FT1AKs2yJu1HZCGVklYm79S Q1MrOVGZPywkDSJGpuGpvLRy81GkjeTzpWk9/FF7M3RshAcqR4wt4J2Eq8uK6A== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1697788921; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AVM/DO9hPX/HC+aIcLv1OaWWQdOPuPcK8XTJEhv9K68=; b=ZKC5qXTgpwPVZYH0yhV207Ek01UWQhWPo+gIDne8YD5Kl+HwHJOwuskO0R3408p8RNi2zs JYzkBPIaa3DeD9CA== From: "tip-bot2 for Vineeth Pillai (Google)" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: sched/core] sched/fair: Update ->next_balance correctly during newidle balance Cc: "Vineeth Pillai (Google)" , "Joel Fernandes (Google)" , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Mel Gorman , Daniel Bristot de Oliveira , Valentin Schneider , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20231020014031.919742-3-joel@joelfernandes.org> References: <20231020014031.919742-3-joel@joelfernandes.org> MIME-Version: 1.0 Message-ID: <169778892069.3135.14832410141983613183.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The following commit has been merged into the sched/core branch of tip: Commit-ID: 1c0482707c42960ec46b88aadd6bffca8685db11 Gitweb: https://git.kernel.org/tip/1c0482707c42960ec46b88aadd6bffca8685db11 Author: Vineeth Pillai (Google) AuthorDate: Fri, 20 Oct 2023 01:40:28 Committer: Ingo Molnar CommitterDate: Fri, 20 Oct 2023 09:56:21 +02:00 sched/fair: Update ->next_balance correctly during newidle balance When newidle balancing triggers, we see that it constantly clobbers rq->next_balance even when there is no newidle balance happening due to the cost estimates. Due to this, we see that periodic load balance (rebalance_domains) may trigger way more often when the CPU is going in and out of idle at a high rate but is no really idle. Repeatedly triggering load balance there is a bad idea as it is a heavy operation. It also causes increases in softirq. Another issue is ->last_balance is not updated after newidle balance causing mistakes in the ->next_balance calculations. Fix by updating last_balance when a newidle load balance actually happens and then updating next_balance. This is also how it is done in other load balance paths. Testing shows a significant drop in softirqs when running: $ cyclictest -i 100 -d 100 --latency=1000 -D 5 -t -m -q ... goes from ~6,000 to ~800. Co-developed-by: Joel Fernandes (Google) Signed-off-by: Vineeth Pillai (Google) Signed-off-by: Joel Fernandes (Google) Signed-off-by: Ingo Molnar Cc: Peter Zijlstra Cc: Juri Lelli Cc: Vincent Guittot Cc: Dietmar Eggemann Cc: Mel Gorman Cc: Daniel Bristot de Oliveira Cc: Valentin Schneider Link: https://lore.kernel.org/r/20231020014031.919742-3-joel@joelfernandes.org --- kernel/sched/fair.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 8c486ff..393d0dc 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -12122,11 +12122,7 @@ static int newidle_balance(struct rq *this_rq, struct rq_flags *rf) if (!READ_ONCE(this_rq->rd->overload) || (sd && this_rq->avg_idle < sd->max_newidle_lb_cost)) { - - if (sd) - update_next_balance(sd, &next_balance); rcu_read_unlock(); - goto out; } rcu_read_unlock(); @@ -12141,8 +12137,6 @@ static int newidle_balance(struct rq *this_rq, struct rq_flags *rf) int continue_balancing = 1; u64 domain_cost; - update_next_balance(sd, &next_balance); - if (this_rq->avg_idle < curr_cost + sd->max_newidle_lb_cost) break; @@ -12155,6 +12149,8 @@ static int newidle_balance(struct rq *this_rq, struct rq_flags *rf) t1 = sched_clock_cpu(this_cpu); domain_cost = t1 - t0; update_newidle_cost(sd, domain_cost); + sd->last_balance = jiffies; + update_next_balance(sd, &next_balance); curr_cost += domain_cost; t0 = t1;