From: Oleg Nesterov <oleg@tv-sign.ru>
To: Cliff Wickman <cpw@sgi.com>
Cc: linux-kernel@vger.kernel.org, pj@sgi.com
Subject: Re: [PATCH 1/1] hotplug cpu: migrate a task within its cpuset
Date: Thu, 24 May 2007 03:32:01 +0400 [thread overview]
Message-ID: <20070523233201.GA384@tv-sign.ru> (raw)
In-Reply-To: <20070523225657.GA26115@sgi.com>
On 05/23, Cliff Wickman wrote:
>
> On Thu, May 24, 2007 at 01:29:02AM +0400, Oleg Nesterov wrote:
> > Cliff Wickman wrote:
> > >
> > > - * NOTE: interrupts should be disabled by the caller
> > > + * NOTE: interrupts are not disabled by the caller
> > > */
> > > static void move_task_off_dead_cpu(int dead_cpu, struct task_struct *p)
> > > {
> > > @@ -5008,6 +5008,17 @@ restart:
> > > if (dest_cpu == NR_CPUS)
> > > dest_cpu = any_online_cpu(p->cpus_allowed);
> > >
> > > + /* try to stay on the same cpuset */
> > > + if (dest_cpu == NR_CPUS) {
> > > + /*
> > > + * Call to cpuset_cpus_allowed may sleep, so we depend
> > > + * on move_task_off_dead_cpu() being called in a non-critical
> > > + * region.
> > > + */
> > > + p->cpus_allowed = cpuset_cpus_allowed(p);
> > > + dest_cpu = any_online_cpu(p->cpus_allowed);
> > > + }
> >
> > I know nothing about cpuset.c, a _very_ naive question.
>
> Paul Jackson is the cpuset guru.
Hopefully Paul can help us...
> > Do we really need task_lock() (used by cpuset_cpus_allowed) here ?
>
> According to Paul's comment in kernel/cpuset.c
> * It is ok to first take manage_sem, then nest callback_sem. We also
> * require taking task_lock() when dereferencing a tasks cpuset pointer.
> So I'm afraid it is not safe to call guarantee_online_cpus(tsk->cpuset, &mask);
> without it. Could the task not be exiting?
But how task_lock() can help? cpuset_exit() doesn't take it, it changes ->cpuset
lockless. However, it sets ->cpuset = &top_cpuset, and the comment says:
* Don't even think about derefencing 'cs' after the cpuset use count
* goes to zero, except inside a critical section guarded by manage_mutex
* or callback_mutex.
^^^^^^^^^^^^^^
So, perhaps cpuset_lock() should be enough.
(That said, looking at cpuset_exit() I can't understand why callback_mutex is
enough. If it is not, cpuset_cpus_allowed() is not safe either).
> > If not, probably we can make this simpler. CPU_DEAD takes cpuset_lock(),
> > move_task_off_dead_cpu() uses guarantee_online_cpus() which doesn't sleep,
> > so we don't need other changes.
> >
> > Possible?
> >
> > If not, this patch should also change migrate_dead(), it still calls
> > move_task_off_dead_cpu() with irqs disabled, no?
>
> Right, the lock is released but I indeed didn't reenable irqs.
> How would you suggest doing that? The irq state was saved in local
> variable "flags" back in migration_call().
migration_call(CPU_DEAD) is called with irqs enabled.
Oleg.
next prev parent reply other threads:[~2007-05-23 23:32 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-23 21:29 [PATCH 1/1] hotplug cpu: migrate a task within its cpuset Oleg Nesterov
2007-05-23 22:56 ` Cliff Wickman
2007-05-23 23:32 ` Oleg Nesterov [this message]
-- strict thread matches above, loose matches on Subject: below --
2007-08-24 22:18 Cliff Wickman
2007-08-24 22:54 ` Andrew Morton
2007-08-25 9:47 ` Oleg Nesterov
2007-08-26 0:16 ` Gautham R Shenoy
2007-08-26 0:47 ` Rusty Russell
2007-08-26 8:09 ` Andrew Morton
2007-08-27 7:01 ` Rusty Russell
2007-08-25 9:58 ` Oleg Nesterov
2007-08-25 11:18 ` Oleg Nesterov
2007-05-22 20:53 Cliff Wickman
2007-05-21 20:08 Cliff Wickman
2007-05-23 17:43 ` Andrew Morton
2007-05-24 7:56 ` Ingo Molnar
2007-05-29 19:32 ` Andrew Morton
2007-03-09 19:39 Cliff Wickman
2007-03-09 23:58 ` Nathan Lynch
2007-03-15 0:36 ` Robin Holt
2007-03-15 7:32 ` Nathan Lynch
2007-03-10 9:19 ` Ingo Molnar
2007-03-10 15:51 ` Nathan Lynch
2007-03-10 17:08 ` Ingo Molnar
2007-03-07 14:24 Cliff Wickman
2007-03-07 18:25 ` Randy Dunlap
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=20070523233201.GA384@tv-sign.ru \
--to=oleg@tv-sign.ru \
--cc=cpw@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pj@sgi.com \
/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.