Received: by 2002:ac8:156:0:b0:3e0:cd10:60c8 with SMTP id f22csp1795384qtg; Wed, 22 Mar 2023 02:11:06 -0700 (PDT) X-Google-Smtp-Source: AK7set+qZSd38anYD1z0tEcrv5iOoR9a4gNCLUU0WUh2SvubulPY6cdaIJx3TS8s1wb3rrl2i2ED X-Received: by 2002:a05:6a20:3541:b0:d8:d720:7fa with SMTP id f1-20020a056a20354100b000d8d72007famr4653539pze.0.1679476265681; Wed, 22 Mar 2023 02:11:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679476265; cv=none; d=google.com; s=arc-20160816; b=yqWmONKR3zOi2JdxnsSe8pj9/m/LKfTSqCF6PaEEYVwY+3x0drSo7SmKoqfYofkZEI mhhmXpmqVSrLSiG/H2FJ+vSxWlxiF27ySS+0cJ+ywXg5+AwvS2xV2xKtAH59fb9ciU/I Kk5I/yvoieRdI1Lxe2RbBNyAw/ggXXfbJDd+3V/oFTMb/G6wPYJMu+WTrlmlM9aTeAS3 cJ0QjV6IcJNtGl3e/69ChPwkuCOgMJyhNpUtPdznTIm50ibEA8+N5Vy3O4X8bP5UH1I8 fYYfqhcZqAOCSzKYoDQMUDz3p/7mH6az80EyyXGh5oudux/mb7NTCuNj9UYSIz3hy//c JWbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:robot-unsubscribe :robot-id:message-id:mime-version:references:in-reply-to:cc:subject :to:reply-to:sender:from:dkim-signature:dkim-signature:date; bh=/MTBir7EOIL7ucr13rJikG5m8y+tjbggVcRsU1LLOh4=; b=XoTHpa7LbFgBhp1+tTJbj8N9vbTJEIQxi0TVjNVwdL/FgHb/jzh8GKUK7jx0k/9YoN 0OEDZKCfHRfMiUwwekWTZSDQ+lJKAjZX4PlFfRURJ516H2tUCfWjidL42QVkUvO/d+J2 1r0Icl1rnsgl/jA8dLd1R56hyAgbjToJQwKYC4AXq7myWe1Q7UtvmK5ub3I2LFZvbSQL 1rp1WnMig082bBEvevQi7zghjFm+yrEEPE5bepCI4iMv4vN91xqaJLDkMpTq/NipMRWI JLovrOLxGQqDZfqmEfFMa8e8ZbUjjVt62ZM7hCdvQM4p+d7FL4rC3nqhbSQAuxxIDMbh 5FcQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=rZvNejBa; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=+oyxZMBR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s13-20020a63924d000000b0050f5a18f73asi11743194pgn.754.2023.03.22.02.10.53; Wed, 22 Mar 2023 02:11:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=rZvNejBa; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=+oyxZMBR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230028AbjCVJHs (ORCPT + 99 others); Wed, 22 Mar 2023 05:07:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56752 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230000AbjCVJHk (ORCPT ); Wed, 22 Mar 2023 05:07:40 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 68F105DED0; Wed, 22 Mar 2023 02:07:17 -0700 (PDT) Date: Wed, 22 Mar 2023 09:07:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1679476034; 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=/MTBir7EOIL7ucr13rJikG5m8y+tjbggVcRsU1LLOh4=; b=rZvNejBaFw3ceqvkkc78OpBPcGMRNnr90PNemGUB0EnKkR78Qzw06blRlIjhlcnT7utRWF ExTak4EHEAX3MrlFCulVoC+G8onHqTdC1iI1+NzaQGuZ2nKXk7Fu6kwnWlVuMiACBfigdM ccEeIkCxh2w747HEE25bttDrYpfBr1oVQ5s/58hDAfH/xfRZq6EEOCNW+NCB7mfBEncTFc Wo0zCh/B9r5mYxF3ZDajc0ralHxfE6R/SDjCz0OLWzFnkZ+WGvkEKVg73Z8PCsQfl26C3m npe8yNpywEz4Psr0yffPfKYUoVQZy8u29WqQvLoYIt41YUqql5XlPKjigcM9Lw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1679476034; 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=/MTBir7EOIL7ucr13rJikG5m8y+tjbggVcRsU1LLOh4=; b=+oyxZMBRQschognWNgZy5/G5kR4kO1nxc/n6bQqhFMFXd7a+n3W6+kQQM4OIbWLHqQT11l tmk+tvVU145fDKAg== From: "tip-bot2 for Vincent Guittot" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: sched/urgent] sched/fair: Sanitize vruntime of entity being migrated Cc: Zhang Qiao , Vincent Guittot , "Peter Zijlstra (Intel)" , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20230317160810.107988-1-vincent.guittot@linaro.org> References: <20230317160810.107988-1-vincent.guittot@linaro.org> MIME-Version: 1.0 Message-ID: <167947603333.5837.1459442924981000636.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 X-Spam-Status: No, score=-2.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The following commit has been merged into the sched/urgent branch of tip: Commit-ID: a53ce18cacb477dd0513c607f187d16f0fa96f71 Gitweb: https://git.kernel.org/tip/a53ce18cacb477dd0513c607f187d16f0fa96f71 Author: Vincent Guittot AuthorDate: Fri, 17 Mar 2023 17:08:10 +01:00 Committer: Peter Zijlstra CommitterDate: Tue, 21 Mar 2023 14:43:04 +01:00 sched/fair: Sanitize vruntime of entity being migrated Commit 829c1651e9c4 ("sched/fair: sanitize vruntime of entity being placed") fixes an overflowing bug, but ignore a case that se->exec_start is reset after a migration. For fixing this case, we delay the reset of se->exec_start after placing the entity which se->exec_start to detect long sleeping task. In order to take into account a possible divergence between the clock_task of 2 rqs, we increase the threshold to around 104 days. Fixes: 829c1651e9c4 ("sched/fair: sanitize vruntime of entity being placed") Originally-by: Zhang Qiao Signed-off-by: Vincent Guittot Signed-off-by: Peter Zijlstra (Intel) Tested-by: Zhang Qiao Link: https://lore.kernel.org/r/20230317160810.107988-1-vincent.guittot@linaro.org --- kernel/sched/core.c | 3 ++- kernel/sched/fair.c | 55 +++++++++++++++++++++++++++++++++++--------- 2 files changed, 47 insertions(+), 11 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 488655f..0d18c39 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -2084,6 +2084,9 @@ static inline void dequeue_task(struct rq *rq, struct task_struct *p, int flags) void activate_task(struct rq *rq, struct task_struct *p, int flags) { + if (task_on_rq_migrating(p)) + flags |= ENQUEUE_MIGRATED; + enqueue_task(rq, p, flags); p->on_rq = TASK_ON_RQ_QUEUED; diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 7a1b1f8..6986ea3 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -4648,11 +4648,33 @@ static void check_spread(struct cfs_rq *cfs_rq, struct sched_entity *se) #endif } +static inline bool entity_is_long_sleeper(struct sched_entity *se) +{ + struct cfs_rq *cfs_rq; + u64 sleep_time; + + if (se->exec_start == 0) + return false; + + cfs_rq = cfs_rq_of(se); + + sleep_time = rq_clock_task(rq_of(cfs_rq)); + + /* Happen while migrating because of clock task divergence */ + if (sleep_time <= se->exec_start) + return false; + + sleep_time -= se->exec_start; + if (sleep_time > ((1ULL << 63) / scale_load_down(NICE_0_LOAD))) + return true; + + return false; +} + static void place_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int initial) { u64 vruntime = cfs_rq->min_vruntime; - u64 sleep_time; /* * The 'current' period is already promised to the current tasks, @@ -4684,13 +4706,24 @@ place_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int initial) /* * Pull vruntime of the entity being placed to the base level of - * cfs_rq, to prevent boosting it if placed backwards. If the entity - * slept for a long time, don't even try to compare its vruntime with - * the base as it may be too far off and the comparison may get - * inversed due to s64 overflow. - */ - sleep_time = rq_clock_task(rq_of(cfs_rq)) - se->exec_start; - if ((s64)sleep_time > 60LL * NSEC_PER_SEC) + * cfs_rq, to prevent boosting it if placed backwards. + * However, min_vruntime can advance much faster than real time, with + * the extreme being when an entity with the minimal weight always runs + * on the cfs_rq. If the waking entity slept for a long time, its + * vruntime difference from min_vruntime may overflow s64 and their + * comparison may get inversed, so ignore the entity's original + * vruntime in that case. + * The maximal vruntime speedup is given by the ratio of normal to + * minimal weight: scale_load_down(NICE_0_LOAD) / MIN_SHARES. + * When placing a migrated waking entity, its exec_start has been set + * from a different rq. In order to take into account a possible + * divergence between new and prev rq's clocks task because of irq and + * stolen time, we take an additional margin. + * So, cutting off on the sleep time of + * 2^63 / scale_load_down(NICE_0_LOAD) ~ 104 days + * should be safe. + */ + if (entity_is_long_sleeper(se)) se->vruntime = vruntime; else se->vruntime = max_vruntime(se->vruntime, vruntime); @@ -4770,6 +4803,9 @@ enqueue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int flags) if (flags & ENQUEUE_WAKEUP) place_entity(cfs_rq, se, 0); + /* Entity has migrated, no longer consider this task hot */ + if (flags & ENQUEUE_MIGRATED) + se->exec_start = 0; check_schedstat_required(); update_stats_enqueue_fair(cfs_rq, se, flags); @@ -7657,9 +7693,6 @@ static void migrate_task_rq_fair(struct task_struct *p, int new_cpu) /* Tell new CPU we are migrated */ se->avg.last_update_time = 0; - /* We have migrated, no longer consider this task hot */ - se->exec_start = 0; - update_scan_period(p, new_cpu); }