Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp1482792rwi; Thu, 27 Oct 2022 16:48:43 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6egJgwWyCBOkVTxgmg0gvQhvuZTdevt5NcHbWF7RRQH2vYnA194aVVJQUxD+B7VSV2xrs3 X-Received: by 2002:a17:907:2708:b0:7a6:38d7:5987 with SMTP id w8-20020a170907270800b007a638d75987mr22346520ejk.467.1666914523242; Thu, 27 Oct 2022 16:48:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666914523; cv=none; d=google.com; s=arc-20160816; b=x9wG2HY3nrgG7jTcz9HRIXZgUqLNVAyhkjcW6kIQlg0mbyAnK44nGP/lxfu43zI8P1 0rpm8pFMzV2Dh0dBHQgAMwRcAbrdpChR7ZwJvheb0ur4/leLJnpETwN693fjd0TwezRV nceVAKwEEOlGxRA/sRfiN2nxw23qT/YwN7zEcfqv0NFalp/WgfsKME+8cPOtHEAxTNf/ PgOXSbxhwxhRGDgVVEzVEHBw81rKtPy2FpJKbnxDxt59svfJA86BlRnOlD1t6OwHE2YZ EwGTvfm3Jm4PclvRHUXAimjWYe4cPQV5BF4f1xM6yEFHLt/QANMtAE+Yc9dFkN4y/m1a pKUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=CkAg4Cf2Dr1/ZG6/7TtW6bvWXD4NPZ0KSNCmhf5kxE0=; b=uOB5MOGNyIIGYD+uzwG7ovgdSMJeXy/cFktbtCd84RyktwYhPaACziGZZ1ZSc2JeLZ VxEeUCWZTrnLE1Ryc+kX1Vi5XDuTyjX4bL0Tcja5Ct3iBdmzTl+EXmuosxXcognQGxSs UB2FDHUxJkrmhd3XeF/y/z9RLEuG97D9wF47Xwoq+dIvk9v8Ns8U2Ip3Fsy7l/HUfrpp fUVuTZRKKm+2iieXk94IffQyiyX2350D85aDVbib9YeXUHewP/1JmiMqFeRYXkEXgFZc a08pjjywU09kaHQ/JoRDSkRcYMSfLd00QzvVVQLpUKFNtiyPglTVQknYpUsnxmkgH0sF Nduw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=NFaYACGU; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e14-20020a056402190e00b0045729070194si3192681edz.517.2022.10.27.16.48.17; Thu, 27 Oct 2022 16:48:43 -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=@google.com header.s=20210112 header.b=NFaYACGU; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235409AbiJ0Xea (ORCPT + 99 others); Thu, 27 Oct 2022 19:34:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51332 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235164AbiJ0Xe2 (ORCPT ); Thu, 27 Oct 2022 19:34:28 -0400 Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 40DF2207 for ; Thu, 27 Oct 2022 16:34:25 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id b18so6144081ljr.13 for ; Thu, 27 Oct 2022 16:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=CkAg4Cf2Dr1/ZG6/7TtW6bvWXD4NPZ0KSNCmhf5kxE0=; b=NFaYACGUhqX3+oSi6T4T4MarI8BT/FEzojfdSwXkJA21c7ZoRJ3jAQqyU+BpSp9uPV 0AwMvnVdWTBE6KaNcVCcszSheuGdTUUXKrlHBXS45eL7sdhHm4t2OsJBcnegMePQvVEB /FRDmnCqrA8wRVPlATDqnEP/LpN9Ug+nyopBzb+Ut2XD+4s+Mivy3ukoZgQ31INnwSV4 GC/YX1Xi6g2BtfoyG8MC8Ng94Fjws2K5QTylcBRHtRb0Uzu9uESLn1QSevpsLRSrjtbD o7mIwcoXwSau6yyXGNn4sNg38w/2TV9Iu/RfvBBCYIPgCM7tX5+wpNi4iZ3/VHNp11+s IF5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=CkAg4Cf2Dr1/ZG6/7TtW6bvWXD4NPZ0KSNCmhf5kxE0=; b=fZY0pp/K3/NimkNhxm6JvjoNZoX/b61dhydprtqr6iQxi0jV4EBhX0EXlyIWqBr8C8 auiF4wWr5QiXY3WDxapgefSqmokX+bFhSray0V7VZlGNfi3KMxMXvg27CD/jwVCgOhZk uM/KYN7VXtmn1qp93VPMOZ4dQ/Vr698DsYKglW9LXIvEgRTbXGQe2V8jHmD8VKlCJD4J 2w5hYqe19nWDYUnmoA6JwP12N1d+jDK+8S+95y0oxj7qT9+mVxo7AZxNbYJtF/MtlSJr IlJ9OIghna7D0KYl9+7vRo7sxSvPq5b4l0agB4YHH+ZP6/adJiCK+TDEPheXohGjlGPe x3XA== X-Gm-Message-State: ACrzQf2QvMVYOA+YtoDDOKfBDMEOrxLTGIATtp9ac/omiaAFVij2hLb3 CWXFumHyv2i1jOvNA/9y5tjYhAhl/MiAEFs2hZXvFg== X-Received: by 2002:a2e:9a8f:0:b0:277:2427:53cd with SMTP id p15-20020a2e9a8f000000b00277242753cdmr3694141lji.52.1666913663447; Thu, 27 Oct 2022 16:34:23 -0700 (PDT) MIME-Version: 1.0 References: <20221027081630.34081-1-zhouchuyi@bytedance.com> In-Reply-To: <20221027081630.34081-1-zhouchuyi@bytedance.com> From: Josh Don Date: Thu, 27 Oct 2022 16:34:11 -0700 Message-ID: Subject: Re: [PATCH] sched/fair: favor non-idle group in tick preemption To: Chuyi Zhou Cc: peterz@infradead.org, juri.lelli@redhat.com, mingo@redhat.com, vincent.guittot@linaro.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham 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 Hi Chuyi, On Thu, Oct 27, 2022 at 1:16 AM Chuyi Zhou wrote: > > The non-idle se dominates competition vs the idle se when they > are belong to the same group. We ensure that idle groups would not > preempt non-idle group in wakeup preemption(see check_preempt_wakeup()). > However, this can happen in tick preemption, since check_preempt_tick() > dose not check current/se is idle or not. This patch adds this check. > > Signed-off-by: Chuyi Zhou > --- > kernel/sched/fair.c | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index e4a0b8bd941c..f3324b8753b3 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -4750,6 +4750,7 @@ static void > check_preempt_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr) > { > unsigned long ideal_runtime, delta_exec; > + int cse_is_idle, pse_is_idle; > struct sched_entity *se; > s64 delta; > > @@ -4779,8 +4780,17 @@ check_preempt_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr) > if (delta < 0) > return; > > - if (delta > ideal_runtime) > + if (delta > ideal_runtime) { > + /* > + * Favor non-idle group even in tick preemption > + */ > + cse_is_idle = se_is_idle(curr); > + pse_is_idle = se_is_idle(se); > + if (unlikely(!cse_is_idle && pse_is_idle)) > + return; This would make it so that we never have tick based preemption of a non-idle entity by an idle entity. That's a recipe for starvation of the idle entity, if the non-idle entity is cpu bound. Beyond that though, I'm not quite sure the issue being solved here. The large difference in weight between the idle and non-idle entity means that the non-idle entity will not be preempted for quite a while due to its ideal_runtime being quite high. The idle entity will quickly be preempted on the next tick it takes due to the smaller value of sysctl_sched_idle_min_granularity. The wakeup check is useful for latency sensitive non-idle tasks. However, in steady state competition between idle and non-idle, we must allow some amount of round-robin. > + > resched_curr(rq_of(cfs_rq)); > + } > } > > static void > -- > 2.20.1 > Best, Josh