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;
Message-ID: <5de97c7f-2c71-34d0-9443-27f71960b4dd@bytedance.com>
Date:   Tue, 15 Mar 2022 10:04:55 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: [External] Re: Subject: [PATCH] sched/fair: prioritize normal
 task over sched_idle task with vruntime offset
To:     Josh Don <joshdon@google.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
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>
From:   chenying <chenying.kernel@bytedance.com>
In-Reply-To: <CABk29NsBEZ63eQ-avDBHe1LYj+wJNSTkCxPDQ=eTNS9_i9e0NA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

在 2022/3/15 8:30, Josh Don 写道:
> 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.