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:   Tue, 19 Jan 2021 17:42:44 +0000
From:   Qais Yousef <qais.yousef@....com>
To:     Quentin Perret <qperret@...gle.com>
Cc:     "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        linux-kernel@...r.kernel.org,
        Valentin Schneider <valentin.schneider@....com>,
        Morten Rasmussen <morten.rasmussen@....com>
Subject: Re: [PATCH] sched/eas: Don't update misfit status if the task is
 pinned

On 01/19/21 16:55, Quentin Perret wrote:
> On Tuesday 19 Jan 2021 at 16:40:27 (+0000), Qais Yousef wrote:
> > On 01/19/21 15:35, Quentin Perret wrote:
> > > Do you mean failing the sched_setaffinity syscall if e.g. the task
> > > has a min clamp that is higher than the capacity of the CPUs to which it
> > > will be pinned? If so, I'm not sure if we really want that.
> > 
> > No. In Android for instance, I'm worried a background task affined to little
> > cores that has a utilization > capacity_of(little) will trigger the same
> > problem. It'll be affined to more than just 1 cpu, but none of the little cpus
> > will actually fit.
> > 
> > Makes sense?
> 
> Now yes.
> 
> I agree this may be a real problem, but capacity_of() very much is a
> per-CPU thing, because of RT pressure and such, and that is not a static
> thing by any mean. So, even if the task doesn't fit on any CPU _now_ we
> might still want to mark it misfit, just so it can be picked up by a
> potential idle balance on another CPU later on. Maybe capacity_orig_of
> would be preferable?

Hmm IIUC you want to still tag it as misfit so it'll be balanced within the
little cores in case there's another core with more spare capacity, right?

This needs more thinking. Misfit doesn't seem the right mechanism to handle
this. If there are multiple tasks crammed on the same CPU, then we should try
to distribute yes. If it is the only task I can't see this being useful unless
the pressure is very high. Which could be an indication of another problem in
the system..

Thanks

--
Qais Yousef

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ