Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp1615663pxb; Tue, 17 Aug 2021 16:42:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJypdMKA/GNYxFrOi9V5gn5jecc5bF1+n0hd0keb1c1F7gCXdQVJC6DtA9y+vCQzFbHwJCZW X-Received: by 2002:a17:906:f92:: with SMTP id q18mr6792632ejj.353.1629243773674; Tue, 17 Aug 2021 16:42:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629243773; cv=none; d=google.com; s=arc-20160816; b=Wxi1xkJtRh/x8fYmc6vDDscHSvawyrNRe5m4Dt5UWed/3WvQnBOoyNpBXdaV68P01C wozSe1NFSfegFU6hLeqeICIRgbmvBxEqQSFnh7ULpqmSoqJLJOyyfQcjckOoxIRIFRYp uYitr351y++LLJcZI05jTnRGWI11T86mMR34NUm7J79UC2tEihlrp78LkoWtcwroh3Ct a3NIaEmBgr81eBQZNQjslG9gZUvhQ7GHFkW4v4ci+SgoXP9s1Nbhg5dztc+dgFAxu+PM y5miDKz98dQ2En+a2u2DOv74ADYzIympnICSCGIcEzPOjRQ5YCMHuZlBm75Gni2yZIGl Ud9A== 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=knpl+46Cr7F/GMqnnEG5MUMV687us2ycCYdc7oiiCkY=; b=mWOzPS4r44qGtHTVPMKnQ2Ncx0tthdaBJ4/zSakhgeuB0fBZJxAZNbEe7z44yd8uOX 7NphEZDbK7mUjUmUzm1Mm9C1LxH7hzQqVRTyqsmHhcPyKToJaM0n1IrN88YerddOZz89 enFLpajdwemFC8cR80rLUuwTC0rIaHt+kVoprpDYnLXLRnyJxhNvg3vFDLDg73+w0ayH YU5vwoYyokHx8kiEoWMmeOrafWG9re3bPVlyO2E0N1FtEVrh/h87kAeyJ9nTg4ucYCIk dsg71AGWGrJJcdm5IN8MoEh/8aAXKcCPrJmF3jBW5jhwf/B4sy5JQlK/b4/w83VTfCJs cLsg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="J/U+aVal"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k24si3822809edv.610.2021.08.17.16.42.29; Tue, 17 Aug 2021 16:42:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="J/U+aVal"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S233024AbhHQXlq (ORCPT + 99 others); Tue, 17 Aug 2021 19:41:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42026 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234753AbhHQXlo (ORCPT ); Tue, 17 Aug 2021 19:41:44 -0400 Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9E1D8C061764 for ; Tue, 17 Aug 2021 16:41:10 -0700 (PDT) Received: by mail-yb1-xb29.google.com with SMTP id a126so1635955ybg.6 for ; Tue, 17 Aug 2021 16:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=knpl+46Cr7F/GMqnnEG5MUMV687us2ycCYdc7oiiCkY=; b=J/U+aValtjtC7cziUESaHLVCLFeee4yR8OjFXpjfe0xQnGLyG9q4abMwkDE4vAvEyE i33AhQS0jye0glM7fgd11Qh8Fk5uCVykwLi+SGqIfQVzCVc1mVOwrUayk/eSFE6Fhxgv v4+Jrb9JrS/KuWwmu++1XmDU8YQMi5jyB3pkaUJzipQi6hEHtaKgzgc2l1Sqahks4Fno fV4q5qeQMZ4Y1qXpaPLIEDxKjIeCmWPMx8Mvq5BJj9q8f03oF7Udt6XdRoHfI0T2ds4j Yz5W3cj8GPArrvdRqkwvNC0tUcISbspEUh+BEqNvSAsCx8DLvjUzFPJdTXz+Cb7RtgiZ WLgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=knpl+46Cr7F/GMqnnEG5MUMV687us2ycCYdc7oiiCkY=; b=a5hbGdIgP3iUP62qqad0eiocdIkXYAHx46ZuEsWJNx/A30IzE3jnNKtTt/lP6Z5RCq VPERaG7KA6yr5M6Rbs1/A43tX1+7eLzJwHeKBRv6RotT6oek04Dsnane/rQpppMQdlMy 6LbUiX5SZtNJTuNx+2zGchiYAuuqweKLdplXRmi47Wu+R4eFjLcQg1B4DP7aVBtvC2SW DKyHYHD7UkDtfyxcTMXTXbc3ldpnivIbKbFdPk/ewc8GihCd1bvDbQhrYDLOmwELceS6 6CQkw002PDmvXs8Ut51Yz9jTekF2txWPXO3ZAcj/XRSW7MD2VOliA7RKK93XijhjyIke sHIQ== X-Gm-Message-State: AOAM5337lrZ0X+t64mI+3bkwRlj+IGvsb6dkGEwHswVLD5FTCcul5jEo Ht1KYuog3AoGbIhcIi+GVeOZN8vyk8q6tdZkDDXCGQ== X-Received: by 2002:a25:1506:: with SMTP id 6mr7466072ybv.153.1629243669454; Tue, 17 Aug 2021 16:41:09 -0700 (PDT) MIME-Version: 1.0 References: <20210730020019.1487127-1-joshdon@google.com> <20210730020019.1487127-3-joshdon@google.com> In-Reply-To: From: Josh Don Date: Tue, 17 Aug 2021 16:40:58 -0700 Message-ID: Subject: Re: [PATCH 2/2] sched: adjust SCHED_IDLE interactions To: Peter Zijlstra Cc: Vincent Guittot , Ingo Molnar , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Paul Turner , Oleg Rombakh , Viresh Kumar , Steve Sistare , Tejun Heo , Rik van Riel , linux-kernel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 16, 2021 at 5:52 AM Peter Zijlstra wrote: > > On Wed, Aug 11, 2021 at 03:31:49PM +0200, Vincent Guittot wrote: > > On Fri, 30 Jul 2021 at 04:00, Josh Don wrote: > > > > > @@ -4216,7 +4228,15 @@ place_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int initial) > > > if (sched_feat(GENTLE_FAIR_SLEEPERS)) > > > thresh >>= 1; > > > > > > - vruntime -= thresh; > > > + /* > > > + * Don't give sleep credit to a SCHED_IDLE entity if we're > > > + * placing it onto a cfs_rq with non SCHED_IDLE entities. > > > + */ > > > + if (!se_is_idle(se) || > > > + cfs_rq->h_nr_running == cfs_rq->idle_h_nr_running) > > I really dislike that second clause, either never do this for idle or > always, but not sometimes when the planets are aligned just right. Yep, switched this to always for idle entities. > > > Can't this condition above create unfairness between idle entities ? > > idle thread 1 wake up while normal thread is running > > normal thread thread sleeps immediately after > > idle thread 2 wakes up just after and gets some credits compared to the 1st one. > > No. Strictly speaking cfs is unfair here. But it's a really tricky case. > > Consider a task that is running 50% competing against a task that's > running 100%. What's fair in that situation, a 50/50 split, or a 25/75 > split? What if that 50% is 50% of a minute? > > What we do here is fudge the vruntime such that we end up with a 50/50 > split provided the period over which it blocks is less than a slice. > After that it gradually converges to the 'expected' 25/75 split that > results from strict runnable competition. > > By not letting idle tasks participate in this, we avoid idle tasks > 'stealing' the !runnable time and they revert back to strict runnable > competition only. I like Vincent's suggestion to use a reduced threshold for idle entities, that's been working pretty well. And it retains some idle<->idle fairness when we have idle waking onto other idle threads.