[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ba44b3fe-352c-384e-5bde-c26e3a03011d@redhat.com>
Date: Wed, 23 Sep 2020 19:54:20 +0200
From: Daniel Bristot de Oliveira <bristot@...hat.com>
To: peterz@...radead.org, Thomas Gleixner <tglx@...utronix.de>
Cc: mingo@...nel.org, linux-kernel@...r.kernel.org,
bigeasy@...utronix.de, qais.yousef@....com, swood@...hat.com,
valentin.schneider@....com, juri.lelli@...hat.com,
vincent.guittot@...aro.org, dietmar.eggemann@....com,
rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
vincent.donnefort@....com
Subject: Re: [PATCH 7/9] sched: Add migrate_disable()
On 9/23/20 7:08 PM, peterz@...radead.org wrote:
> On Wed, Sep 23, 2020 at 10:31:10AM +0200, Thomas Gleixner wrote:
>> In practice migrate disable could be taken into account on placement
>> decisions, but yes we don't have anything like that at the moment.
> I think at the very least we should do some of that.
>
> The premise is wanting to run the M highest priority tasks, when a CPU
> drops priority, it tries to PULL a higher priority task towards itself.
> If this PULL selects a migrate_disable() tasks, it means the task is in
> the M highest prio tasks.
>
> Since obviously that task cannot get pulled, we should then pull the
> current running task of that CPU, this would then allow the
> migrate_disable() task to resume execution.
>
> I'll go try and cook up something along those lines...
>
sounds promising...
-- Daniel
Powered by blists - more mailing lists