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 X-Spam-Level: X-Spam-Status: No, score=-10.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 57F2EC4338F for ; Mon, 16 Aug 2021 12:57:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3AA9E6327E for ; Mon, 16 Aug 2021 12:57:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235275AbhHPM5m (ORCPT ); Mon, 16 Aug 2021 08:57:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42964 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229839AbhHPM5l (ORCPT ); Mon, 16 Aug 2021 08:57:41 -0400 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C0B3BC061764 for ; Mon, 16 Aug 2021 05:57:09 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id w20so34218041lfu.7 for ; Mon, 16 Aug 2021 05:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rsZbwogPh/AZ096p40e3Illwraa2Wp4Sz1Xn9F07NkY=; b=F/HjoMoSBRQx7O3rJjSKgw+9Y0wXMncq0MMTz8S7BnxM2e9Iv7JPu+4npLw5JpteKf KQsqqlPXITDdg2/w0w7Y6Bi7vB7fo3bbfzquvYSBaqGCYfEhWhxojM8qiawaaakZqSSj GzdoV81BLgKbkGGQ3RiCYSUA3w1o82Lx5MG0gv1UPNoF+O8eAv8hIqwvi7VbEsjIOH0f 8mqm53eq+dIs4EoOBnxfqkrPhPCGjERwEFsfoRuXDqeYXEsqLGAOCn0RlPrxqtqeKPH9 74of8opK5oPhfvG1fbKsEle6YbzTAcYLvgGNBxjtKABVA7xGo8a/7T4Eyho0pMnXp5VE uHxA== 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=rsZbwogPh/AZ096p40e3Illwraa2Wp4Sz1Xn9F07NkY=; b=X2EUjuGomVv4vSp369VG/0AEq77fV/knTsMlCEDEcGLq8WDNDYQ+0797hHvCyn4OlA LDca5YqBeqKsnxF4Kd840PrRw7alYo2qG4D7Q2u0nS+jjBO5lQ/V82PbfkSTI44z6K1i F+n3QGFpRfL+Hp3sZ5NHXNGCpmaXmNMfhINWDUhEfLfOZ/+vhxH5/WacOq+3BMXnTUbD X3YL8F9eVwZTDyNIwNPg1f6OsVaWSjgZL8DGM1Jg6rh2sY9GvOSYF9Znhmm1ACHZWpoo gsUEgR+eyqBHv2Jro76CrjVc1SnFUSIQ14/nP4DKpAeh1xLXiUYG9iQCpxCynDmS2skm cWSA== X-Gm-Message-State: AOAM533k8mNaxSgMx0l6RbNYQuOOgPm1gUqU4aMQTt0i6WOPZ7OBdll1 Lrp0WA/6/A2zl7nrV7B9SOxUwy7Trnwuj/iYey0ffQ== X-Google-Smtp-Source: ABdhPJyt2LM/X6WRHuXQbW9qfjxD4LEdZWv/ACuaKTruy1hSh5nQFOWqwmBEVDelJJo+RvYqJmMM1YTZbloW/jKfxkg= X-Received: by 2002:a05:6512:3f89:: with SMTP id x9mr11835532lfa.233.1629118628129; Mon, 16 Aug 2021 05:57:08 -0700 (PDT) MIME-Version: 1.0 References: <20210730020019.1487127-1-joshdon@google.com> <20210730020019.1487127-3-joshdon@google.com> In-Reply-To: From: Vincent Guittot Date: Mon, 16 Aug 2021 14:56:57 +0200 Message-ID: Subject: Re: [PATCH 2/2] sched: adjust SCHED_IDLE interactions To: Peter Zijlstra Cc: Josh Don , 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, 16 Aug 2021 at 14:52, 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. That was my point too > > > 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. > > > > + vruntime -= thresh; > > > + else > > > + vruntime += 1; > > > } > > > > > > /* ensure we never gain time by being placed backwards. */ > > > -- > > > 2.32.0.554.ge1b32706d8-goog > > >