From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Oleg Nesterov <oleg@tv-sign.ru>,
ego@in.ibm.com, akpm@osdl.org, paulmck@us.ibm.com, mingo@elte.hu,
vatsa@in.ibm.com, dipankar@in.ibm.com,
venkatesh.pallipadi@intel.com, linux-kernel@vger.kernel.org,
Pavel Machek <pavel@ucw.cz>
Subject: Re: freezer problems
Date: Wed, 21 Feb 2007 10:27:52 -0800 [thread overview]
Message-ID: <20070221182752.GE7063@linux.vnet.ibm.com> (raw)
In-Reply-To: <200702211913.41883.rjw@sisk.pl>
On Wed, Feb 21, 2007 at 07:13:40PM +0100, Rafael J. Wysocki wrote:
> On Wednesday, 21 February 2007 19:14, Paul E. McKenney wrote:
> > On Tue, Feb 20, 2007 at 07:29:01PM +0100, Rafael J. Wysocki wrote:
> > > On Tuesday, 20 February 2007 01:32, Rafael J. Wysocki wrote:
> > > > On Tuesday, 20 February 2007 01:12, Oleg Nesterov wrote:
> > > > Hm. In the case discussed above we have a task that's right before calling
> > > > frozen_process(), so we can't thaw it, because it's not frozen. It will be
> > > > frozen just in a while, but try_to_freeze_tasks() and thaw_tasks() have no
> > > > way to check this.
> > > >
> > > > I think to close this race the refrigerator should check TIF_FREEZE and set
> > > > PF_FROZEN _and_ reset TIF_FREEZE under a lock that would also have to be
> > > > taken by try_to_freeze_tasks() in the beginning of the error path. This will
> > > > ensure that all tasks either freeze themselves before the error path in
> > > > try_to_freeze_tasks() is executed, or remain unfrozen.
> > > >
> > > > I'll try to prepare a patch to illustrate this, but right now I'm too tired to
> > > > do it. :-)
> > >
> > > Something like this, perhaps:
> > >
> > > ---
> > > include/linux/freezer.h | 10 +++-------
> > > kernel/power/process.c | 18 ++++++++++++++++--
> > > 2 files changed, 19 insertions(+), 9 deletions(-)
> > >
> > > Index: linux-2.6.20-mm2/include/linux/freezer.h
> > > ===================================================================
> > > --- linux-2.6.20-mm2.orig/include/linux/freezer.h
> > > +++ linux-2.6.20-mm2/include/linux/freezer.h
> > > @@ -58,17 +58,13 @@ static inline void frozen_process(struct
> > > clear_tsk_thread_flag(p, TIF_FREEZE);
> > > }
> > >
> > > -extern void refrigerator(void);
> > > +extern int refrigerator(void);
> > > extern int freeze_processes(void);
> > > extern void thaw_processes(void);
> > >
> > > static inline int try_to_freeze(void)
> > > {
> > > - if (freezing(current)) {
> > > - refrigerator();
> > > - return 1;
> > > - } else
> > > - return 0;
> > > + return refrigerator();
> > > }
> > >
> > > /*
> > > @@ -104,7 +100,7 @@ static inline void freeze(struct task_st
> > > static inline int thaw_process(struct task_struct *p) { return 1; }
> > > static inline void frozen_process(struct task_struct *p) { BUG(); }
> > >
> > > -static inline void refrigerator(void) {}
> > > +static inline int refrigerator(void) { return 0; }
> > > static inline int freeze_processes(void) { BUG(); return 0; }
> > > static inline void thaw_processes(void) {}
> > >
> > > Index: linux-2.6.20-mm2/kernel/power/process.c
> > > ===================================================================
> > > --- linux-2.6.20-mm2.orig/kernel/power/process.c
> > > +++ linux-2.6.20-mm2/kernel/power/process.c
> > > @@ -24,6 +24,8 @@
> > > #define FREEZER_KERNEL_THREADS 0
> > > #define FREEZER_USER_SPACE 1
> > >
> > > +spinlock_t refrigerator_lock;
> > > +
> > > static inline int freezeable(struct task_struct * p)
> > > {
> > > if ((p == current) ||
> > > @@ -34,15 +36,23 @@ static inline int freezeable(struct task
> > > }
> > >
> > > /* Refrigerator is place where frozen processes are stored :-). */
> > > -void refrigerator(void)
> > > +int refrigerator(void)
> > > {
> > > /* Hmm, should we be allowed to suspend when there are realtime
> > > processes around? */
> > > long save;
> > > +
> > > + spin_lock(&refrigerator_lock);
> >
> > I hope we can do this without a global lock that is acquired on each
> > try_to_freeze() call!
>
> Yes. Here's the current version (try_to_freeze() is unchanged, so the lock
> is only taken by the tasks that are going to freeze, or so they think):
Ah, OK, that should work much better from a lock-contention viewpoint!
Thanx, Paul
> ---
> kernel/power/process.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> Index: linux-2.6.20-mm2/kernel/power/process.c
> ===================================================================
> --- linux-2.6.20-mm2.orig/kernel/power/process.c
> +++ linux-2.6.20-mm2/kernel/power/process.c
> @@ -24,6 +24,8 @@
> #define FREEZER_KERNEL_THREADS 0
> #define FREEZER_USER_SPACE 1
>
> +static spinlock_t refrigerator_lock;
> +
> static inline int freezeable(struct task_struct * p)
> {
> if ((p == current) ||
> @@ -39,10 +41,18 @@ void refrigerator(void)
> /* Hmm, should we be allowed to suspend when there are realtime
> processes around? */
> long save;
> +
> + spin_lock(&refrigerator_lock);
> + if (freezing(current)) {
> + frozen_process(current);
> + spin_unlock(&refrigerator_lock);
> + } else {
> + spin_unlock(&refrigerator_lock);
> + return;
> + }
> save = current->state;
> pr_debug("%s entered refrigerator\n", current->comm);
>
> - frozen_process(current);
> spin_lock_irq(¤t->sighand->siglock);
> recalc_sigpending(); /* We sent fake signal, clean it up */
> spin_unlock_irq(¤t->sighand->siglock);
> @@ -143,6 +153,7 @@ static unsigned int try_to_freeze_tasks(
> "kernel threads",
> TIMEOUT / HZ, todo);
> read_lock(&tasklist_lock);
> + spin_lock(&refrigerator_lock);
> do_each_thread(g, p) {
> if (is_user_space(p) == !freeze_user_space)
> continue;
> @@ -152,6 +163,7 @@ static unsigned int try_to_freeze_tasks(
>
> cancel_freezing(p);
> } while_each_thread(g, p);
> + spin_unlock(&refrigerator_lock);
> read_unlock(&tasklist_lock);
> }
>
> @@ -169,6 +181,7 @@ int freeze_processes(void)
> unsigned int nr_unfrozen;
>
> printk("Stopping tasks ... ");
> + spin_lock_init(&refrigerator_lock);
> nr_unfrozen = try_to_freeze_tasks(FREEZER_USER_SPACE);
> if (nr_unfrozen)
> return nr_unfrozen;
next prev parent reply other threads:[~2007-02-21 18:27 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-14 14:40 [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug Gautham R Shenoy
2007-02-14 14:42 ` [RFC PATCH(Experimental) 1/4] freezer-cpu-hotplug core Gautham R Shenoy
2007-02-14 14:43 ` [RFC PATCH(Experimental) 2/4] Revert changes to workqueue.c Gautham R Shenoy
2007-02-14 14:43 ` [RFC PATCH(Experimental) 3/4] Revert changes to sched.c and slab.c Gautham R Shenoy
2007-02-14 14:44 ` [RFC PATCH(Experimental) 4/4] Rip out lock_cpu_hotplug from linux Gautham R Shenoy
2007-02-14 14:59 ` [RFC PATCH(Experimental) 2/4] Revert changes to workqueue.c Srivatsa Vaddagiri
2007-02-14 15:24 ` Srivatsa Vaddagiri
2007-02-14 20:23 ` Oleg Nesterov
2007-02-14 20:09 ` Oleg Nesterov
2007-02-16 5:26 ` Srivatsa Vaddagiri
2007-02-16 15:33 ` Oleg Nesterov
2007-02-16 16:47 ` Srivatsa Vaddagiri
2007-02-16 18:45 ` Oleg Nesterov
2007-02-16 23:59 ` Oleg Nesterov
2007-02-17 2:29 ` Srivatsa Vaddagiri
2007-02-17 21:59 ` Oleg Nesterov
2007-02-20 15:12 ` Srivatsa Vaddagiri
2007-02-20 20:09 ` Oleg Nesterov
2007-02-21 6:29 ` Srivatsa Vaddagiri
2007-02-21 14:30 ` Oleg Nesterov
2007-02-21 14:37 ` Gautham R Shenoy
2007-02-21 15:53 ` Srivatsa Vaddagiri
2007-02-14 15:31 ` [RFC PATCH(Experimental) 1/4] freezer-cpu-hotplug core Srivatsa Vaddagiri
2007-02-14 19:47 ` Oleg Nesterov
2007-02-16 6:48 ` Srivatsa Vaddagiri
2007-02-16 15:47 ` Oleg Nesterov
2007-02-14 20:22 ` Oleg Nesterov
2007-02-16 7:16 ` Srivatsa Vaddagiri
2007-02-16 8:12 ` Srivatsa Vaddagiri
2007-02-16 9:29 ` Rafael J. Wysocki
2007-02-16 9:59 ` Srivatsa Vaddagiri
2007-02-16 11:06 ` Rafael J. Wysocki
2007-02-16 19:46 ` Oleg Nesterov
2007-02-17 2:31 ` Srivatsa Vaddagiri
2007-02-17 5:32 ` Gautham R Shenoy
2007-02-17 11:19 ` Gautham R Shenoy
2007-02-16 16:06 ` Oleg Nesterov
2007-02-14 21:43 ` [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug Rafael J. Wysocki
2007-02-15 6:34 ` Gautham R Shenoy
2007-02-15 8:09 ` Rafael J. Wysocki
2007-02-15 12:20 ` Gautham R Shenoy
2007-02-15 13:31 ` Rafael J. Wysocki
2007-02-15 14:25 ` Gautham R Shenoy
2007-02-17 11:24 ` Rafael J. Wysocki
2007-02-17 21:34 ` Oleg Nesterov
2007-02-17 22:24 ` Rafael J. Wysocki
2007-02-17 23:42 ` Oleg Nesterov
2007-02-17 23:47 ` Oleg Nesterov
2007-02-18 10:43 ` Rafael J. Wysocki
2007-02-18 11:31 ` Oleg Nesterov
2007-02-18 12:14 ` Rafael J. Wysocki
2007-02-18 14:52 ` freezer problems Oleg Nesterov
2007-02-18 15:14 ` Rafael J. Wysocki
2007-02-18 16:19 ` Oleg Nesterov
2007-02-18 18:14 ` Rafael J. Wysocki
2007-02-18 18:56 ` Rafael J. Wysocki
2007-02-18 22:01 ` Oleg Nesterov
2007-02-18 23:19 ` Rafael J. Wysocki
2007-02-19 20:23 ` Oleg Nesterov
2007-02-19 21:21 ` Rafael J. Wysocki
2007-02-19 22:41 ` Oleg Nesterov
2007-02-19 23:35 ` Rafael J. Wysocki
2007-02-20 0:12 ` Oleg Nesterov
2007-02-20 0:32 ` Rafael J. Wysocki
2007-02-20 0:50 ` Oleg Nesterov
2007-02-20 18:28 ` Rafael J. Wysocki
2007-02-20 18:29 ` Rafael J. Wysocki
2007-02-21 18:14 ` Paul E. McKenney
2007-02-21 18:13 ` Rafael J. Wysocki
2007-02-21 18:27 ` Paul E. McKenney [this message]
2007-02-21 20:03 ` Oleg Nesterov
2007-02-21 20:47 ` Rafael J. Wysocki
2007-02-21 21:06 ` Paul E. McKenney
2007-02-21 23:10 ` Rafael J. Wysocki
2007-02-22 10:47 ` Oleg Nesterov
2007-02-22 11:33 ` Oleg Nesterov
2007-02-22 17:03 ` Rafael J. Wysocki
2007-02-22 17:44 ` Oleg Nesterov
2007-02-22 21:56 ` Rafael J. Wysocki
2007-02-23 18:15 ` Oleg Nesterov
2007-02-23 3:02 ` Gautham R Shenoy
2007-02-18 15:09 ` [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug Rafael J. Wysocki
2007-02-18 16:11 ` Oleg Nesterov
2007-02-18 18:51 ` Rafael J. Wysocki
2007-02-18 10:32 ` Rafael J. Wysocki
2007-02-18 11:32 ` Oleg Nesterov
2007-02-18 12:12 ` Rafael J. Wysocki
2007-02-18 15:06 ` Oleg Nesterov
2007-02-18 12:56 ` Pavel Machek
2007-02-21 14:52 ` Gautham R Shenoy
2007-02-21 19:42 ` Pavel Machek
[not found] ` <200702231041.17136.rjw@sisk.pl>
[not found] ` <20070223100817.GA10973@in.ibm.com>
[not found] ` <200702231115.00718.rjw@sisk.pl>
[not found] ` <20070223104723.GB10973@in.ibm.com>
[not found] ` <20070223110201.GC10973@in.ibm.com>
2007-02-23 19:03 ` freezer problems Gautham R Shenoy
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=20070221182752.GE7063@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akpm@osdl.org \
--cc=dipankar@in.ibm.com \
--cc=ego@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=oleg@tv-sign.ru \
--cc=paulmck@us.ibm.com \
--cc=pavel@ucw.cz \
--cc=rjw@sisk.pl \
--cc=vatsa@in.ibm.com \
--cc=venkatesh.pallipadi@intel.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.