From nobody Tue Apr 7 18:09:43 2026 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 123CCC28D13 for ; Thu, 25 Aug 2022 12:27:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241073AbiHYM1m (ORCPT ); Thu, 25 Aug 2022 08:27:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59130 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240538AbiHYM1f (ORCPT ); Thu, 25 Aug 2022 08:27:35 -0400 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 22B15B2874 for ; Thu, 25 Aug 2022 05:27:34 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id k9so24420779wri.0 for ; Thu, 25 Aug 2022 05:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=references:in-reply-to:message-id:date:subject:cc:to:from:from:to :cc; bh=1jOusZgKkm5WANPXGaVYE6KRJlFGGUsuCyFNE7JUooM=; b=CEA9syvDnBy12AASzhjTKQePZq/nDobaYDFG33wpBoHuTYHBS+aGzekCp/7KATl82q pneAop0fiEfoG1GSROoAovfj7ob6z6FPikrFGC/Q01FKgXeAjKKTktGrS2XHQnGbo7lv DOpasbdR3Ggjn3/S7XEkZyJkvycx8YgKfGsdF6S3WW8MkgZfZKvMw1jPKLrsCIdKKjYP TBRBNdt9MAsxZLop6/5VMDXe4jPte55IrtJz7zxExSqKXzdxLHlYgcrAwOS2OzBX7e/u BiQZ1ue8UVldKu93ERpMi460AcuS31+lx3z3Q0YSqRk6+FTuEnFcVlADiKl2l84E+SiK UXjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:in-reply-to:message-id:date:subject:cc:to:from :x-gm-message-state:from:to:cc; bh=1jOusZgKkm5WANPXGaVYE6KRJlFGGUsuCyFNE7JUooM=; b=inPw6XkyHAMHvL3BPa9Ezhc58DljzBD4UYFNplB044KHAwoAH8hqnXnJ/xvsm3qDoz NWSWj31mjNwaaHt3Dhy6vX/ACEnMecwQ7BaS2FqbsfPEXLtgt4hGXGn9mEAifqI6P7WB aHRjGiuoM3axrWp7z0Cv0JUJ0Rwlzghfq9DjBBSAKmnhi6gbJYlX3XEOpJkNyg5NY5JT 4cvXm/jojtr3R67Q9o2ZXQsLLM1YYm8iYXCSp64zkHk4eAtL61e0qjjgEXVEKJwsyMrR QiILZoCZt4qbD2qnt/8FBzZlE1reuDivZx/JIOaduKZIXZW5Xmzo48Wb4GjKC6pxNKU8 BBAQ== X-Gm-Message-State: ACgBeo33CR0gwJQ0YE/SANELfeyzNxjbhZgD7gSQ/N4Rq861xS5mxar7 fx5uLxKJ1xneNk7T5yMPRaUvCA== X-Google-Smtp-Source: AA6agR7TQhU8j0DY68b9wCi9Eo1yLjeb7HaOm3n9AMlTFOh/dP+I8ZeHbohu7+HoxNJ9ofbOw3FFGg== X-Received: by 2002:a5d:47cc:0:b0:225:7827:70d4 with SMTP id o12-20020a5d47cc000000b00225782770d4mr2104040wrc.315.1661430452431; Thu, 25 Aug 2022 05:27:32 -0700 (PDT) Received: from localhost.localdomain ([2a01:e0a:f:6020:55dd:3519:10d3:b07b]) by smtp.gmail.com with ESMTPSA id c7-20020a05600c0ac700b003a5ee64cc98sm5417809wmr.33.2022.08.25.05.27.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Aug 2022 05:27:30 -0700 (PDT) From: Vincent Guittot To: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, bristot@redhat.com, vschneid@redhat.com, linux-kernel@vger.kernel.org Cc: zhangqiao22@huawei.com, Vincent Guittot Subject: [PATCH 1/4] sched/fair: make sure to try to detach at least one movable task Date: Thu, 25 Aug 2022 14:27:23 +0200 Message-Id: <20220825122726.20819-2-vincent.guittot@linaro.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20220825122726.20819-1-vincent.guittot@linaro.org> References: <20220825122726.20819-1-vincent.guittot@linaro.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" During load balance, we try at most env->loop_max time to move a task. But it can happen that the loop_max LRU tasks (ie tail of the cfs_tasks list) can't be moved to dst_cpu because of affinity. In this case, loop in the list until we found at least one. The maximum of detached tasks remained the same as before. Signed-off-by: Vincent Guittot --- kernel/sched/fair.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index da388657d5ac..02b7b808e186 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -8052,8 +8052,12 @@ static int detach_tasks(struct lb_env *env) p =3D list_last_entry(tasks, struct task_struct, se.group_node); =20 env->loop++; - /* We've more or less seen every task there is, call it quits */ - if (env->loop > env->loop_max) + /* + * We've more or less seen every task there is, call it quits + * unless we haven't found any movable task yet. + */ + if (env->loop > env->loop_max && + !(env->flags & LBF_ALL_PINNED)) break; =20 /* take a breather every nr_migrate tasks */ @@ -10182,7 +10186,9 @@ static int load_balance(int this_cpu, struct rq *th= is_rq, =20 if (env.flags & LBF_NEED_BREAK) { env.flags &=3D ~LBF_NEED_BREAK; - goto more_balance; + /* Stop if we tried all running tasks */ + if (env.loop < busiest->nr_running) + goto more_balance; } =20 /* --=20 2.17.1 From nobody Tue Apr 7 18:09:43 2026 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 447CFC04AA5 for ; Thu, 25 Aug 2022 12:27:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235466AbiHYM1r (ORCPT ); Thu, 25 Aug 2022 08:27:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59180 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241053AbiHYM1i (ORCPT ); Thu, 25 Aug 2022 08:27:38 -0400 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3A2B4B2874 for ; Thu, 25 Aug 2022 05:27:36 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id d16so19114746wrr.3 for ; Thu, 25 Aug 2022 05:27:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=references:in-reply-to:message-id:date:subject:cc:to:from:from:to :cc; bh=ey0d/hNz+WJSmxzAyykGWkMsVcT2Dh56xgrxsVx/5u8=; b=x+8Ga+cmw96a9rXHj/vdfDsewY1McTjVu5a/ii18p2qC2Pq9XcWL4OIh1ECiJDonQp vFddVMFtvuQ69H7C3grF/mZsTuVHt8RLBvpOwCvmQQJKP2K4Kqnj0aLg6DiW+NxAXofd kt/TG4d77cNkhHEpax3zYH4rlxGAzlmu4f9hZ1VkQQ2irQZ0SrxYCYlp7G0mwzahFC8U OI8KPAEF8TMyd/2pTrOI7fN+YlizmG4H58ZQpsnvCFsrhHP94/NddDSBBhbfZB8F1k2e +9WMx6JsXxBLJfoc1oUGYfOsuX1JnvBep7o0E99E83Wo8oTjymiGCUMxK7ajgyJ6F2n/ bc7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:in-reply-to:message-id:date:subject:cc:to:from :x-gm-message-state:from:to:cc; bh=ey0d/hNz+WJSmxzAyykGWkMsVcT2Dh56xgrxsVx/5u8=; b=uK/PMTzTfHhWtd+4mW7pcCjoJY4LI54/nM5zhVXGpE3yFlyg7MUnVXWs0aU7B054F1 GHJzGIxh8iYG4SxvqPHPnX3UTbkuZKpgYqC8AwBGTtma/CJPhe2Ab5WSsUMtAJF+FEg8 Is0Lk8s64Xqxp1C52UhqaagQhiqzC4FxvFVIlNgMrlEmwqCg0sBlZ/0rA8szTEKj+xUY qv7NxviJU5GuOjnScGg9yrY80o4okUwnfr7lhbjVj3HtbVIcuD79pBrPe7NL9KijRwLQ 8SWAX0RTjApG3+9j7ZiDq7vHfTaTPRWEmDihybneqzRsUQXfV8To4sFYtD/+7JtUpngc 89uA== X-Gm-Message-State: ACgBeo3xun2G8q8o8pFOpcIVuhsDpg+lYBF6wN0RV2KIGDxwx/rEf/r0 xRrs5oaYKxtQkpP7tU0m4LWBqQ== X-Google-Smtp-Source: AA6agR4vV6U5GvuBop4sIQKJT1oVJBqezBH/HO9I94/Eal3M/oIedxhbm1wwynBeZ5iZK5AqkrnF2g== X-Received: by 2002:a05:6000:168e:b0:220:87da:c3f5 with SMTP id y14-20020a056000168e00b0022087dac3f5mr2126988wrd.166.1661430454594; Thu, 25 Aug 2022 05:27:34 -0700 (PDT) Received: from localhost.localdomain ([2a01:e0a:f:6020:55dd:3519:10d3:b07b]) by smtp.gmail.com with ESMTPSA id c7-20020a05600c0ac700b003a5ee64cc98sm5417809wmr.33.2022.08.25.05.27.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Aug 2022 05:27:33 -0700 (PDT) From: Vincent Guittot To: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, bristot@redhat.com, vschneid@redhat.com, linux-kernel@vger.kernel.org Cc: zhangqiao22@huawei.com, Vincent Guittot Subject: [PATCH 2/4] sched/fair: cleanup loop_max and loop_break Date: Thu, 25 Aug 2022 14:27:24 +0200 Message-Id: <20220825122726.20819-3-vincent.guittot@linaro.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20220825122726.20819-1-vincent.guittot@linaro.org> References: <20220825122726.20819-1-vincent.guittot@linaro.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" sched_nr_migrate_break is set to a fix value and never changes so we can replace it by a define SCHED_NR_MIGRATE_BREAK. Also, we adjust SCHED_NR_MIGRATE_BREAK to be aligned with the init value of sysctl_sched_nr_migrate which can be init to different values. Then, use SCHED_NR_MIGRATE_BREAK to init sysctl_sched_nr_migrate. The behavior stays unchanged unless you modify sysctl_sched_nr_migrate trough debugfs. Signed-off-by: Vincent Guittot --- kernel/sched/core.c | 6 +----- kernel/sched/fair.c | 11 ++++------- kernel/sched/sched.h | 6 ++++++ 3 files changed, 11 insertions(+), 12 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 64c08993221b..a21e817bdd1c 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -142,11 +142,7 @@ __read_mostly int sysctl_resched_latency_warn_once =3D= 1; * Number of tasks to iterate in a single balance run. * Limited because this is done with IRQs disabled. */ -#ifdef CONFIG_PREEMPT_RT -const_debug unsigned int sysctl_sched_nr_migrate =3D 8; -#else -const_debug unsigned int sysctl_sched_nr_migrate =3D 32; -#endif +const_debug unsigned int sysctl_sched_nr_migrate =3D SCHED_NR_MIGRATE_BREA= K; =20 __read_mostly int scheduler_running; =20 diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 02b7b808e186..6972a1a29a48 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -8012,8 +8012,6 @@ static struct task_struct *detach_one_task(struct lb_= env *env) return NULL; } =20 -static const unsigned int sched_nr_migrate_break =3D 32; - /* * detach_tasks() -- tries to detach up to imbalance load/util/tasks from * busiest_rq, as part of a balancing operation within domain "sd". @@ -8062,7 +8060,7 @@ static int detach_tasks(struct lb_env *env) =20 /* take a breather every nr_migrate tasks */ if (env->loop > env->loop_break) { - env->loop_break +=3D sched_nr_migrate_break; + env->loop_break +=3D SCHED_NR_MIGRATE_BREAK; env->flags |=3D LBF_NEED_BREAK; break; } @@ -10103,14 +10101,13 @@ static int load_balance(int this_cpu, struct rq *= this_rq, struct rq *busiest; struct rq_flags rf; struct cpumask *cpus =3D this_cpu_cpumask_var_ptr(load_balance_mask); - struct lb_env env =3D { .sd =3D sd, .dst_cpu =3D this_cpu, .dst_rq =3D this_rq, .dst_grpmask =3D sched_group_span(sd->groups), .idle =3D idle, - .loop_break =3D sched_nr_migrate_break, + .loop_break =3D SCHED_NR_MIGRATE_BREAK, .cpus =3D cpus, .fbq_type =3D all, .tasks =3D LIST_HEAD_INIT(env.tasks), @@ -10219,7 +10216,7 @@ static int load_balance(int this_cpu, struct rq *th= is_rq, env.dst_cpu =3D env.new_dst_cpu; env.flags &=3D ~LBF_DST_PINNED; env.loop =3D 0; - env.loop_break =3D sched_nr_migrate_break; + env.loop_break =3D SCHED_NR_MIGRATE_BREAK; =20 /* * Go back to "more_balance" rather than "redo" since we @@ -10251,7 +10248,7 @@ static int load_balance(int this_cpu, struct rq *th= is_rq, */ if (!cpumask_subset(cpus, env.dst_grpmask)) { env.loop =3D 0; - env.loop_break =3D sched_nr_migrate_break; + env.loop_break =3D SCHED_NR_MIGRATE_BREAK; goto redo; } goto out_all_pinned; diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index 3ccd35c22f0f..d5cfd1b5bfe9 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -2423,6 +2423,12 @@ extern void deactivate_task(struct rq *rq, struct ta= sk_struct *p, int flags); =20 extern void check_preempt_curr(struct rq *rq, struct task_struct *p, int f= lags); =20 +#ifdef CONFIG_PREEMPT_RT +#define SCHED_NR_MIGRATE_BREAK 8 +#else +#define SCHED_NR_MIGRATE_BREAK 32 +#endif + extern const_debug unsigned int sysctl_sched_nr_migrate; extern const_debug unsigned int sysctl_sched_migration_cost; =20 --=20 2.17.1 From nobody Tue Apr 7 18:09:43 2026 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 332ACC04AA5 for ; Thu, 25 Aug 2022 12:28:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239596AbiHYM14 (ORCPT ); Thu, 25 Aug 2022 08:27:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59332 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241057AbiHYM1m (ORCPT ); Thu, 25 Aug 2022 08:27:42 -0400 Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 718EDB2CD1 for ; Thu, 25 Aug 2022 05:27:38 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id bs25so24426986wrb.2 for ; Thu, 25 Aug 2022 05:27:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=references:in-reply-to:message-id:date:subject:cc:to:from:from:to :cc; bh=3bBUsI0/teu1SGpGTa+Jbt56cw9thfDxAuVHauIJcr4=; b=wDcdvn9n+ukcoBqV1qJlvuH5bk4MBjNC0WGzpX+j68yBvwUlNF45KAf1BfBuI8A4jB adSZf4/KKaWAVAnKxv/HWdUemw/1Uc3nnNBFm3EOmvihVsrAuopXeBjJ+CM4UJ41axnO nL0vIAeOWwV4Q+XsFIBLWjvtBuG0v1bLDkA4PMof6vi6QJh4LVzWSxfGX53J1LqmkNF4 9pb6MMfSgV2OwiFio512IB9WZEf//+LiIgDtAzr44uYjlSBTzt2+D1rVl15fSIeColnF 7ZJs/KvCsSK1xtKBneh4XfdhWw5Lz/+0xud+/FjKc+2XKJMvfi7QpGY4qC+eg1W5Taul fiMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:in-reply-to:message-id:date:subject:cc:to:from :x-gm-message-state:from:to:cc; bh=3bBUsI0/teu1SGpGTa+Jbt56cw9thfDxAuVHauIJcr4=; b=1YpnnuZXGaU74hv71v8TF/j0mI35UUrWm68dNoc8MiqKS8G/tK2vQn58s0/zr2z/eH V2wAVyJ0Pia2d9Usl+LtPky2g1lmxP94+KkmrzwmeA6VoN52F6lmuMvKhwz14UoSanLp 5G2Y9nLT2hdaZzDfnRGORyzNAMNRCfetviLUoiycAKO+wbb+Rd8AouUojkDhUbyqscpF 5WDMdgPODexmabqNwYwgsmOKdfwkaJFjwRRljcJeQo61rH4k5p2/0fPQ2FOV2pqBJ7BL 41nost3kINEKoYrykeRG4EccXawpG0C3ovrEbGaVLt5DA2DNXPpIhPmiXOKvSy6VyypE ef2g== X-Gm-Message-State: ACgBeo2rKN4t+n7YPi7on5FOK7tRzuF7bzyRINpP3NfF0hPcfb1j7ZnO kB82RFmk5D7ldxhSVOnm4+zJdw== X-Google-Smtp-Source: AA6agR7wn5PGajPD4/BbEjbqGbOm6JA3c4Unu2o8aL5mYu4gaY6cWdew2B7umdMm4FwK2sp4GgtsCw== X-Received: by 2002:a5d:64cf:0:b0:220:6d8e:1db0 with SMTP id f15-20020a5d64cf000000b002206d8e1db0mr2081414wri.564.1661430456817; Thu, 25 Aug 2022 05:27:36 -0700 (PDT) Received: from localhost.localdomain ([2a01:e0a:f:6020:55dd:3519:10d3:b07b]) by smtp.gmail.com with ESMTPSA id c7-20020a05600c0ac700b003a5ee64cc98sm5417809wmr.33.2022.08.25.05.27.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Aug 2022 05:27:35 -0700 (PDT) From: Vincent Guittot To: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, bristot@redhat.com, vschneid@redhat.com, linux-kernel@vger.kernel.org Cc: zhangqiao22@huawei.com, Vincent Guittot Subject: [PATCH 3/4] sched/fair: move call to list_last_entry() in detach_tasks Date: Thu, 25 Aug 2022 14:27:25 +0200 Message-Id: <20220825122726.20819-4-vincent.guittot@linaro.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20220825122726.20819-1-vincent.guittot@linaro.org> References: <20220825122726.20819-1-vincent.guittot@linaro.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Move the call to list_last_entry() in detach_tasks() after testing loop_max and loop_break. Signed-off-by: Vincent Guittot Reviewed-by: Dietmar Eggemann --- kernel/sched/fair.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 6972a1a29a48..260a55ac462f 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -8047,8 +8047,6 @@ static int detach_tasks(struct lb_env *env) if (env->idle !=3D CPU_NOT_IDLE && env->src_rq->nr_running <=3D 1) break; =20 - p =3D list_last_entry(tasks, struct task_struct, se.group_node); - env->loop++; /* * We've more or less seen every task there is, call it quits @@ -8065,6 +8063,8 @@ static int detach_tasks(struct lb_env *env) break; } =20 + p =3D list_last_entry(tasks, struct task_struct, se.group_node); + if (!can_migrate_task(p, env)) goto next; =20 --=20 2.17.1 From nobody Tue Apr 7 18:09:43 2026 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 D1041C04AA5 for ; Thu, 25 Aug 2022 12:28:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241706AbiHYM2K (ORCPT ); Thu, 25 Aug 2022 08:28:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59372 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241223AbiHYM1n (ORCPT ); Thu, 25 Aug 2022 08:27:43 -0400 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C1E07B2CE5 for ; Thu, 25 Aug 2022 05:27:40 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id a4so24445762wrq.1 for ; Thu, 25 Aug 2022 05:27:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=references:in-reply-to:message-id:date:subject:cc:to:from:from:to :cc; bh=OicpysW7udmsv4B07ks66/QAA2RjLzfuKutZRyo1XJE=; b=vfLmlICKCQ/ZWNvLSXgoFzeF4gHctCgY+Npj5h2sAzoyAVyTKWIbyhYQF30J/SZoYX UxJd0tggPT98340Ffr50EINkMtWMxqk/Qle7dj89A0bp7E1s+jpfS8X91AggWHk7aKPe CiXrFz/+ghAf3DXH5+kahul45rCVMiBoOd/QEbXTmUJqpDaV8tu0ZIywZb/hI4dFqwhe 7H/LlpAp9NIywK6+VY3NsrAK2NBU4VBmbzJ3txZtcoDjb1pVxaIxx9DelShndtFHAaUf kNEpNkDsSJ75iCgoiAhvop8CXYRBGVidRoUX28dFKtl9Ht728pNDY40/TyyZ49zqH9tK stqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:in-reply-to:message-id:date:subject:cc:to:from :x-gm-message-state:from:to:cc; bh=OicpysW7udmsv4B07ks66/QAA2RjLzfuKutZRyo1XJE=; b=TmG97tKhnBWeJTSSx9nqtKX3OC2ltJg89XWv2uQ90lnJyGGLR2kzuNigFrRgL1dr17 KbxagrRs/lJTxVcumsOSkwUMjM2wHOF0++M55qNHvO147iTJTKr/s0bHz7Y6UenDY2no br5VEmld3BGmclNw3t1BH4TT6dZRLP2MGZbTrxa2Lok9tbaVUhY/zWorLmrh33azGhKg 1Z2oYuIxf8QwdNgmwsENiCIp9HYelOK0pihUwZg+vC28itsMZctD3LP32ShLgdBd1Jbt CbGpe+fh9wjqkw6XN9YIroD/ihW65Iy+wSvAymnAJCIJfonv5/kAA0xvh5rFjZ1N0hXe K/Sw== X-Gm-Message-State: ACgBeo0ybTDJl439n9cchYoZj0oj5YxzjGRcc+0rkbWY2NuLeTPgwTLW 3JNEVsSGxjBv3j5xZIVpuKQxcw== X-Google-Smtp-Source: AA6agR4LranD4hpHty2xtQQcuuwqnjLOPL6610SQl/HOXmdHnUkyyz9P/+Ee3wX6/IPtf8y1sC+wqg== X-Received: by 2002:a5d:5402:0:b0:225:3a78:4d2c with SMTP id g2-20020a5d5402000000b002253a784d2cmr2251680wrv.675.1661430458875; Thu, 25 Aug 2022 05:27:38 -0700 (PDT) Received: from localhost.localdomain ([2a01:e0a:f:6020:55dd:3519:10d3:b07b]) by smtp.gmail.com with ESMTPSA id c7-20020a05600c0ac700b003a5ee64cc98sm5417809wmr.33.2022.08.25.05.27.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Aug 2022 05:27:37 -0700 (PDT) From: Vincent Guittot To: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, bristot@redhat.com, vschneid@redhat.com, linux-kernel@vger.kernel.org Cc: zhangqiao22@huawei.com, Vincent Guittot Subject: [PATCH 4/4] sched/fair: limit sched slice duration Date: Thu, 25 Aug 2022 14:27:26 +0200 Message-Id: <20220825122726.20819-5-vincent.guittot@linaro.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20220825122726.20819-1-vincent.guittot@linaro.org> References: <20220825122726.20819-1-vincent.guittot@linaro.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" In presence of a lot of small weight tasks like sched_idle tasks, normal or high weight tasks can see their ideal runtime (sched_slice) to increase to hundreds ms whereas it normally stays below sysctl_sched_latency. 2 normal tasks running on a CPU will have a max sched_slice of 12ms (half of the sched_period). This means that they will make progress every sysctl_sched_latency period. If we now add 1000 idle tasks on the CPU, the sched_period becomes 3006 ms and the ideal runtime of the normal tasks becomes 609 ms. It will even become 1500ms if the idle tasks belongs to an idle cgroup. This means that the scheduler will look for picking another waiting task after 609ms running time (1500ms respectively). The idle tasks change significantly the way the 2 normal tasks interleave their running time slot whereas they should have a small impact. Such long sched_slice can delay significantly the release of resources as the tasks can wait hundreds of ms before the next running slot just because of idle tasks queued on the rq. Cap the ideal_runtime to sysctl_sched_latency when comparing to the next waiting task to make sure that tasks will regularly make progress and will not be significantly impacted by idle/background tasks queued on the rq. Signed-off-by: Vincent Guittot --- While studying the problem, I have also considered to substract cfs.idle_h_nr_running before computing the sched_slice but we can have quite similar problem with low weight bormal task/cgroup so I have decided to keep this solution. Also, this solution doesn't completly remove the impact of idle tasks in the scheduling pattern but cap the running slice of a task to a max value of 2*sysctl_sched_latency. kernel/sched/fair.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 260a55ac462f..96fedd0ab5fa 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -4599,6 +4599,8 @@ check_preempt_tick(struct cfs_rq *cfs_rq, struct sche= d_entity *curr) if (delta < 0) return; =20 + ideal_runtime =3D min_t(u64, ideal_runtime, sysctl_sched_latency); + if (delta > ideal_runtime) resched_curr(rq_of(cfs_rq)); } --=20 2.17.1