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;
MIME-Version: 1.0
References: <f87a8c0d-527d-a9bc-9653-ff955e0e95b4@bytedance.com>
 <20220312120309.GB6235@worktop.programming.kicks-ass.net> <a528d7bf-a634-00b6-42ab-dcb516567c34@bytedance.com>
 <20220313090222.GL28057@worktop.programming.kicks-ass.net>
 <e57c7166-b484-0d32-e4e8-5a47ef0bb53c@bytedance.com> <CABk29NsBEZ63eQ-avDBHe1LYj+wJNSTkCxPDQ=eTNS9_i9e0NA@mail.gmail.com>
 <5de97c7f-2c71-34d0-9443-27f71960b4dd@bytedance.com>
In-Reply-To: <5de97c7f-2c71-34d0-9443-27f71960b4dd@bytedance.com>
From:   Josh Don <joshdon@google.com>
Date:   Mon, 14 Mar 2022 19:21:40 -0700
Message-ID: <CABk29NskiBBk--FJDux34mt-iQnZ4L-_p9XPtKUerFbtr5AMcQ@mail.gmail.com>
Subject: Re: [External] Re: Subject: [PATCH] sched/fair: prioritize normal
 task over sched_idle task with vruntime offset
To:     chenying <chenying.kernel@bytedance.com>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>,
        Juri Lelli <juri.lelli@redhat.com>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Mel Gorman <mgorman@suse.de>,
        Daniel Bristot de Oliveira <bristot@redhat.com>,
        Benjamin Segall <bsegall@google.com>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        duanxiongchun@bytedance.com, zhouchengming@bytedance.com,
        songmuchun@bytedance.com, zhengqi.arch@bytedance.com,
        zhoufeng.zf@bytedance.com, ligang.bdlg@bytedance.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, Mar 14, 2022 at 7:05 PM chenying <chenying.kernel@bytedance.com> wr=
ote:
>
> =E5=9C=A8 2022/3/15 8:30, Josh Don =E5=86=99=E9=81=93:
> > On Sun, Mar 13, 2022 at 3:07 AM chenying <chenying.kernel@bytedance.com=
> wrote:
> >>
> >> If I set the sched_idle_vruntime_offset to a relatively small value
> >> (e.g. 10 minutes), can this issues be avoided?
> >
> > That's still long enough to cause lockups.
> >
> > Is the issue that you have a large number of sched_idle entities, and
> > the occasional latency sensitive thing that wakes up for a short
> > duration? Have you considered approaching this from the other
> > direction (ie. if we have a latency sensitive thing wake onto a cpu
> > running only sched idle stuff, we could change entity placement to
> > position the latency sensitive thing further left on the timeline,
> > akin to !GENTLE_FAIR_SLEEPERS).
>
> I think this may not guarantee that latency sensitive tasks are always
> to the left of idle tasks. And it may get complicated if a
> latency-sensitive task is woken up onto a cpu which there are already
> multiple latency-sensitive tasks and sched_idle tasks.

If you're waking onto a cpu with lots of latency-sensitive tasks
already, you're already outside the bounds of being able to guarantee
the latency tails you're after (given that the default
idle_min_granularity and idle weight aren't giving you the performance
at the tails that you want right now). It would be helpful to get a
clearer statement as to the problem you're trying to solve.

Perhaps Vincent's recent patch series adding latency support to CFS
("Add latency_nice priority") would be of interest?