[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190612173930.GL3402@hirez.programming.kicks-ass.net>
Date: Wed, 12 Jun 2019 19:39:31 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Tejun Heo <tj@...nel.org>
Cc: Joel Savitz <jsavitz@...hat.com>, linux-kernel@...r.kernel.org,
Li Zefan <lizefan@...wei.com>, Phil Auld <pauld@...hat.com>,
Waiman Long <longman@...hat.com>,
Michal Koutný <mkoutny@...e.com>,
Ingo Molnar <mingo@...hat.com>, cgroups@...r.kernel.org
Subject: Re: [RESEND PATCH v3] cpuset: restore sanity to
cpuset_cpus_allowed_fallback()
On Wed, Jun 12, 2019 at 09:02:44AM -0700, Tejun Heo wrote:
> On Wed, Jun 12, 2019 at 11:50:48AM -0400, Joel Savitz wrote:
> > In the case that a process is constrained by taskset(1) (i.e.
> > sched_setaffinity(2)) to a subset of available cpus, and all of those are
> > subsequently offlined, the scheduler will set tsk->cpus_allowed to
> > the current value of task_cs(tsk)->effective_cpus.
> >
> > This is done via a call to do_set_cpus_allowed() in the context of
> > cpuset_cpus_allowed_fallback() made by the scheduler when this case is
> > detected. This is the only call made to cpuset_cpus_allowed_fallback()
> > in the latest mainline kernel.
> >
> > However, this is not sane behavior.
>
> While not perfect (we'll need to stop updating task's cpumask from
> cpuset to make), this is still a signifcant improvement.
>
> Acked-by: Tejun Heo <tj@...nel.org>
>
> If there's no objection, I'll route it through the cgroup tree.
Acked-by: Peter Zijlstra (Intel) <peterz@...radead.org>
Powered by blists - more mailing lists