linux-kernel - Re: [PATCH] sched: Take thermal pressure into account when determine rt fits capacity

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]

Date:   Wed, 27 Apr 2022 09:38:26 +0800
From:   Xuewen Yan <xuewen.yan94@...il.com>
To:     Qais Yousef <qais.yousef@....com>
Cc:     Xuewen Yan <xuewen.yan@...soc.com>, dietmar.eggemann@....com,
        lukasz.luba@....com, rafael@...nel.org, viresh.kumar@...aro.org,
        mingo@...hat.com, peterz@...radead.org, vincent.guittot@...aro.org,
        rostedt@...dmis.org, linux-kernel@...r.kernel.org,
        di.shen@...soc.com
Subject: Re: [PATCH] sched: Take thermal pressure into account when determine
 rt fits capacity

> > > The best (simplest) way forward IMHO is to introduce a new function
> > >
> > >         bool cpu_in_capacity_inversion(int cpu);
> > >
> > > (feel free to pick another name) which will detect the scenario you're in. You
> > > can use this function then in rt_task_fits_capacity()
> > >
> > >         diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
> > >         index a32c46889af8..d48811a7e956 100644
> > >         --- a/kernel/sched/rt.c
> > >         +++ b/kernel/sched/rt.c
> > >         @@ -462,6 +462,9 @@ static inline bool rt_task_fits_capacity(struct task_struct *p, int cpu)
> > >                 if (!static_branch_unlikely(&sched_asym_cpucapacity))
> > >                         return true;
> > >
> > >         +       if (cpu_in_capacity_inversion(cpu))
> > >         +               return false;
> > >         +
> > >                 min_cap = uclamp_eff_value(p, UCLAMP_MIN);
> > >                 max_cap = uclamp_eff_value(p, UCLAMP_MAX);
> > >
> > > You'll probably need to do something similar in dl_task_fits_capacity().
> > >
> > > This might be a bit aggressive though as we'll steer away all RT tasks from
> > > this CPU (as long as there's another CPU that can fit it). I need to think more
> > > about it. But we could do something like this too
> > >
> > >         diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
> > >         index a32c46889af8..f2a34946a7ab 100644
> > >         --- a/kernel/sched/rt.c
> > >         +++ b/kernel/sched/rt.c
> > >         @@ -462,11 +462,14 @@ static inline bool rt_task_fits_capacity(struct task_struct *p, int cpu)
> > >                 if (!static_branch_unlikely(&sched_asym_cpucapacity))
> > >                         return true;
> > >
> > >         +       cpu_cap = capacity_orig_of(cpu);
> > >         +
> > >         +       if (cpu_in_capacity_inversion(cpu))
> >
> > It's  a good idea, but as you said, in mainline, the
> > sysctl_sched_uclamp_util_min_rt_default is always 1024,
> > Maybe it's better to add it to the judgment?
>
> I don't think so. If we want to handle finding the next best thing, we need to
> make the search more complex than that. This is no worse than having 2 RT tasks
> waking up at the same time while there's only a single big CPU. One of them
> will end up on a medium or a little and we don't provide better guarantees
> here.

I may have misunderstood your patch before, do you mean this:
1. the cpu has to be inversion, if not, the cpu's capacity is still
the biggest, although the sysctl_sched_uclamp_util_min_rt_default
=1024, it still can put on the cpu.
2. If the cpu is inversion, the thermal pressure should be considered,
at this time, if the sysctl_sched_uclamp_util_min_rt_default is not
1024, make the rt still have chance to select the cpu.
    If the sysctl_sched_uclamp_util_min_rt_default is 1024, all of the
cpu actually can not fit the rt, at this time, select cpu without
considering the cap_orig_of(cpu). The worst thing may be that  rt
would put on the small core.

I understand right? If so, Perhaps this approach has the least impact
on the current code complexity.

Thanks!
BR
---
xuewen