All of lore.kernel.org
 help / color / mirror / Atom feed
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
Date: Tue, 19 Jan 2021 16:55:16 +0000	[thread overview]
Message-ID: <YAcO9HHHVBx7oBG/@google.com> (raw)
In-Reply-To: <20210119164027.drfpmrol3xhf4ckc@e107158-lin>

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

  reply	other threads:[~2021-01-19 18:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-19 12:07 [PATCH] sched/eas: Don't update misfit status if the task is pinned Qais Yousef
2021-01-19 12:24 ` Valentin Schneider
2021-01-19 13:34 ` Vincent Guittot
2021-01-19 13:54   ` Valentin Schneider
2021-01-19 14:19     ` Vincent Guittot
2021-01-19 16:55       ` Valentin Schneider
2021-01-19 17:06         ` Vincent Guittot
2021-01-19 15:35 ` Quentin Perret
2021-01-19 16:40   ` Qais Yousef
2021-01-19 16:55     ` Quentin Perret [this message]
2021-01-19 17:42       ` Qais Yousef
2021-01-19 17:50         ` Quentin Perret
2021-01-20 11:57           ` Qais Yousef

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YAcO9HHHVBx7oBG/@google.com \
    --to=qperret@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=morten.rasmussen@arm.com \
    --cc=peterz@infradead.org \
    --cc=qais.yousef@arm.com \
    --cc=valentin.schneider@arm.com \
    --cc=vincent.guittot@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.