linux-kernel - Re: [External] Re: [PATCH 0/2] Fix nohz

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 for Android: free password hash cracker in your pocket

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

Message-ID: <bd786914-4718-7a35-fcc1-9cdee58d2f06@bytedance.com>
Date:   Fri, 8 Sep 2023 10:57:26 +0800
From:   Hao Jia <jiahao.os@...edance.com>
To:     Phil Auld <pauld@...hat.com>
Cc:     mingo@...hat.com, peterz@...radead.org, mingo@...nel.org,
        juri.lelli@...hat.com, vincent.guittot@...aro.org,
        dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
        mgorman@...e.de, bristot@...hat.com, vschneid@...hat.com,
        linux-kernel@...r.kernel.org
Subject: Re: [External] Re: [PATCH 0/2] Fix nohz_full vs rt bandwidth



On 2023/9/7 Phil Auld wrote:
> Hi Hao,
> 
> On Wed, Sep 06, 2023 at 02:45:39PM +0800 Hao Jia wrote:
>>
>> Friendly ping...
>>
>> On 2023/8/21 Hao Jia wrote:
>>> Since the commit 88c56cfeaec4 ("sched/fair: Block nohz tick_stop
>>> when cfs bandwidth in use") was merged, it handles conflicts between
>>> NOHZ full and cfs_bandwidth well, and the scheduler feature HZ_BW
>>> allows us to choose which one to prefer.
>>>
>>> This conflict also exists between NOHZ full and rt_bandwidth,
>>> these two patches try to handle it in a similar way.
>>>
> 
> Are you actually hitting this in the real world?
> 
> We, for example, no longer enable RT_GROUP_SCHED so this is a non-issue
> for our use cases.  I'd recommend considering that. (Does it even
> work with cgroup2?)
> 

Yes, it has always been there. Regardless of whether RT_GROUP_SCHED is 
enabled or not, rt bandwidth is always enabled. If RT_GROUP_SCHED is not 
enabled, all rt tasks in the system are a group, and rt_runtime is 
950000, and rt_period is 1000000.So rt bandwidth is always enabled by 
default.


Thanks,
Hao

> In some ways what you have is a simplification of code, but it also
> obfuscates the stop_tick conditions by hiding them all in the class
> specific functions.  It was easier to see why the tick didn't stop
> looking at the original code.
> 
> It would be better to do this only if it is really needed, in my opinion.
> 
> 
> Cheers,
> Phil
> 
>>> patch1: Extracts a can_stop_tick() callback function for each
>>> sched_class from sched_can_stop_tick(), it will make things clearer
>>> and also convenient to handle the conflict between NOHZ full
>>> and rt_bandwidth.
>>>
>>> patch2: If the HZ_BW scheduler feature is enabled, and the RT task
>>> to be run is constrained by rt_bandwidth runtime. Then it will
>>> prevent NO_HZ full from stopping tick.
>>>
>>> Hao Jia (2):
>>>     sched/core: Introduce sched_class::can_stop_tick()
>>>     sched/rt: Block nohz tick_stop when rt bandwidth in use
>>>
>>>    kernel/sched/core.c     | 67 +++++--------------------------
>>>    kernel/sched/deadline.c | 16 ++++++++
>>>    kernel/sched/fair.c     | 56 +++++++++++++++++++++++---
>>>    kernel/sched/rt.c       | 89 ++++++++++++++++++++++++++++++++++++++++-
>>>    kernel/sched/sched.h    |  5 ++-
>>>    5 files changed, 168 insertions(+), 65 deletions(-)
>>>
>>
>