Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 19 Jan 2021 16:55:16 +0000
From:   Quentin Perret <qperret@google.com>
To:     Qais Yousef <qais.yousef@arm.com>
Cc:     "Peter Zijlstra (Intel)" <peterz@infradead.org>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        linux-kernel@vger.kernel.org,
        Valentin Schneider <valentin.schneider@arm.com>,
        Morten Rasmussen <morten.rasmussen@arm.com>
Subject: Re: [PATCH] sched/eas: Don't update misfit status if the task is
 pinned
Message-ID: <YAcO9HHHVBx7oBG/@google.com>
References: <20210119120755.2425264-1-qais.yousef@arm.com>
 <YAb8XGyp3NtrHl+U@google.com>
 <20210119164027.drfpmrol3xhf4ckc@e107158-lin>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210119164027.drfpmrol3xhf4ckc@e107158-lin>
Precedence: bulk

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?

Thanks,
Quentin