[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090802065504.GA27164@redhat.com>
Date: Sun, 2 Aug 2009 08:55:04 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Lai Jiangshan <laijs@...fujitsu.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>,
Rusty Russell <rusty@...tcorp.com.au>,
linux-kernel@...r.kernel.org, Li Zefan <lizf@...fujitsu.com>,
Miao Xie <miaox@...fujitsu.com>,
Paul Menage <menage@...gle.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Gautham R Shenoy <ego@...ibm.com>
Subject: Re: [PATCH] cpusets: rework guarantee_online_cpus() to fix
deadlock with cpu_down()
On 08/02, Lai Jiangshan wrote:
>
> Oleg Nesterov wrote:
>
> >
> > - do NOT scan cs->parent cpusets. If there are no online CPUs in
> > cs->cpus_allowed, we use cpu_online_mask. This is only possible
> > when we are called by cpu_down() hooks, in that case
> > cpuset_track_online_cpus(CPU_DEAD) will fix things later.
> >
>
>
> We must scan cs->parent cpusets.
> A task is constrained by a cpuset,
Yes, the task esacpes its cpuset. With or without this patch.
Because cs->cpus_allowed has no online CPUs.
> it must be constrained
> this cpuset's parent too.
It will be constained again, after scan_for_empty_cpusets(), no?
The only difference this patch adds is that a task temporary uses
cpu_online_mask when its cs->cpuset_allowed becomes empty. Why
this is so bad? This can only happen when CPU dies and cs becomes
empty, force majeure.
Even without this patch, the task is not actually constrained by
its cs->parent. Yes, we use ->parent->cpus_allowed. But this mask
can be changed right after guarantee_online_cpus() returns. And
since this task does not belong to cs->parent cpuset,
update_tasks_cpumask() will not fix this task. Again, until
cpuset_track_online_cpus().
Could you explain what problem this patch adds?
> cpuset_lock() is not awful at all.
OK it is not awful. But surely it complicates things. And currently
it is buggy.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists