[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200702161029.21560.rjw@sisk.pl>
Date: Fri, 16 Feb 2007 10:29:20 +0100
From: "Rafael J. Wysocki" <rjw@...k.pl>
To: vatsa@...ibm.com
Cc: Oleg Nesterov <oleg@...sign.ru>, Gautham R Shenoy <ego@...ibm.com>,
akpm@...l.org, paulmck@...ibm.com, mingo@...e.hu,
dipankar@...ibm.com, venkatesh.pallipadi@...el.com,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH(Experimental) 1/4] freezer-cpu-hotplug core
On Friday, 16 February 2007 09:12, Srivatsa Vaddagiri wrote:
> On Fri, Feb 16, 2007 at 12:46:17PM +0530, Srivatsa Vaddagiri wrote:
> > frozen. The only exception is cleaning up of per-cpu threads (which is
> > not possible with processes frozen - if we can find a way to make that
> > possible, then everything can be done in CPU_DEAD).
>
> How abt a patch like below?
>
>
> --- process.c.org 2007-02-16 13:38:39.000000000 +0530
> +++ process.c 2007-02-16 13:38:59.000000000 +0530
> @@ -47,7 +47,7 @@ void refrigerator(void)
> recalc_sigpending(); /* We sent fake signal, clean it up */
> spin_unlock_irq(¤t->sighand->siglock);
>
> - while (frozen(current)) {
> + while (frozen(current) && !kthread_should_stop()) {
> current->state = TASK_UNINTERRUPTIBLE;
> schedule();
> }
>
> This should let us do kthread_stop() in CPU_DEAD itself (while processes
> are frozen)? That would allow us to do everything from CPU_DEAD itself
> (and not have CPU_DEAD_KILL_THREADS).
Well, the suspend code has been developed with the assumption that frozen
threads stay frozen until _we_ let them thaw by calling thaw_processes(). I'm
a bit afraid of this change.
Greetings,
Rafael
-
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