linux-kernel - Re: [PATCH] sched/fair: favor non-idle group in tick preemption

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e7a5e964-6113-f54d-1477-5eb561f843e3@bytedance.com>
Date:   Tue, 1 Nov 2022 17:14:26 +0800
From:   Abel Wu <wuyun.abel@...edance.com>
To:     Josh Don <joshdon@...gle.com>, Chuyi Zhou <zhouchuyi@...edance.com>
Cc:     peterz@...radead.org, juri.lelli@...hat.com, mingo@...hat.com,
        vincent.guittot@...aro.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched/fair: favor non-idle group in tick preemption

Hi Josh,

On 11/1/22 6:44 AM, Josh Don wrote:
> ...nit...
> Some weirdness about this change though, is that if there is a
> non-idle current entity, and the two next entities on the cfs_rq are
> idle and non-idle respectively, we'll now take longer to preempt the
> on-cpu non-idle entity, because the non-idle entity on the cfs_rq is
> 'hidden' by the idle 'first' entity. Wakeup preemption is different
> because we're always directly comparing the current entity with the
> newly woken entity.

Indeed. The hidden non-idle entity might run longer at the cost of
delayed preemption. This behavior is not compliant to the SCHED_NORMAL
semantics. But we also can't tell from here that the non-idle entity
contains SCHED_NORMAL tasks or not. As long as the entities do not
aware of the schedule policies, this ambiguity exists.

Best,
Abel