From: Nigel Cunningham <nigel@nigel.suspend2.net>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Gautham R Shenoy <ego@in.ibm.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Oleg Nesterov <oleg@tv-sign.ru>, Pavel Machek <pavel@ucw.cz>
Subject: Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default
Date: Tue, 29 May 2007 07:26:22 +1000 [thread overview]
Message-ID: <1180387582.4102.38.camel@nigel.suspend2.net> (raw)
In-Reply-To: <200705282017.51210.rjw@sisk.pl>
[-- Attachment #1: Type: text/plain, Size: 6075 bytes --]
Hi.
On Mon, 2007-05-28 at 20:17 +0200, Rafael J. Wysocki wrote:
> On Monday, 28 May 2007 11:46, Nigel Cunningham wrote:
> > Hello!
> >
> > In reply to your more recent message, I had looked but not tried, so
> > didn't feel in a position to reply yet.
> >
> > On Sun, 2007-05-27 at 00:12 +0200, Rafael J. Wysocki wrote:
> > > 63 files changed, 78 insertions(+), 138 deletions(-)
> >
> > Well, that looks good, for a start :)
> >
> > > Index: linux-2.6.22-rc3/kernel/exit.c
> > > ===================================================================
> > > --- linux-2.6.22-rc3.orig/kernel/exit.c
> > > +++ linux-2.6.22-rc3/kernel/exit.c
> > > @@ -389,6 +389,11 @@ void daemonize(const char *name, ...)
> > > * they would be locked into memory.
> > > */
> > > exit_mm(current);
> > > + /*
> > > + * We don't want to have TIF_FREEZE set if the system-wide hibernation
> > > + * or suspend transision begins right now.
> > > + */
> > > + current->flags |= PF_NOFREEZE;
> >
> > s/transision/transition
>
> Thanks, will fix.
>
> > > set_special_pids(1, 1);
> > > proc_clear_tty(current);
> > > Index: linux-2.6.22-rc3/include/linux/freezer.h
> > > ===================================================================
> > > --- linux-2.6.22-rc3.orig/include/linux/freezer.h
> > > +++ linux-2.6.22-rc3/include/linux/freezer.h
> > > @@ -118,6 +118,14 @@ static inline int freezer_should_skip(st
> > > return !!(p->flags & PF_FREEZER_SKIP);
> > > }
> > >
> > > +/*
> > > + * Tell the freezer that the current task should be frozen by it
> > > + */
> > > +static inline void set_freezable(void)
> > > +{
> > > + current->flags &= ~PF_NOFREEZE;
> > > +}
> > > +
> >
> > Given the clearing of the flag above, should we just have a
> > set_unfreezeable here that's used above (and potentially elsewhere)...
> > (reads more)... or more generic set_[un]freezeable(task_struct *p)
> > routines that could also be used in copy_flags below?
>
> Yes, I can introduce set_unfreezeable(), although that would be used in
> a couple of places only.
>
> I don't think it's a good idea to have set_[un]freezeable(task_struct *p),
> since only current is allowed to set/unset its flags.
The copy_flags routine changes another process's flags - that's why I
was suggesting this.
> > > #else
> > > static inline int frozen(struct task_struct *p) { return 0; }
> > > static inline int freezing(struct task_struct *p) { return 0; }
> > > @@ -134,6 +142,7 @@ static inline int try_to_freeze(void) {
> > > static inline void freezer_do_not_count(void) {}
> > > static inline void freezer_count(void) {}
> > > static inline int freezer_should_skip(struct task_struct *p) { return 0; }
> > > +static inline void set_freezable_current(void) {}
>
> Ah, this is a mistake (wrong name).
>
> > > #endif
> > >
> > > #endif /* LINUX_FREEZER_H */
> > > Index: linux-2.6.22-rc3/kernel/fork.c
> > > ===================================================================
> > > --- linux-2.6.22-rc3.orig/kernel/fork.c
> > > +++ linux-2.6.22-rc3/kernel/fork.c
> > > @@ -920,7 +920,7 @@ static inline void copy_flags(unsigned l
> > > {
> > > unsigned long new_flags = p->flags;
> > >
> > > - new_flags &= ~(PF_SUPERPRIV | PF_NOFREEZE);
> > > + new_flags &= ~PF_SUPERPRIV;
> > > new_flags |= PF_FORKNOEXEC;
> > > if (!(clone_flags & CLONE_PTRACE))
> > > p->ptrace = 0;
> > > Index: linux-2.6.22-rc3/arch/i386/kernel/io_apic.c
> > > ===================================================================
> > > --- linux-2.6.22-rc3.orig/arch/i386/kernel/io_apic.c
> > > +++ linux-2.6.22-rc3/arch/i386/kernel/io_apic.c
> > > @@ -669,7 +669,6 @@ static int balanced_irq(void *unused)
> > >
> > > for ( ; ; ) {
> > > time_remaining = schedule_timeout_interruptible(time_remaining);
> > > - try_to_freeze();
> > > if (time_after(jiffies,
> > > prev_balance_time+balanced_irq_interval)) {
> > > preempt_disable();
> >
> > I'm the one who is confused, aren't I? If I'm reading this right,
> > io_apic used to be frozen. After this patch, it will not be frozen. If
> > that's the intended behaviour, shouldn't this be two patches - one to
> > make kernel threads unfreezeable by default, and one to make threads
> > that were formerly freezeable unfreezeable?
>
> Yes, I think you're right. I tend to try to make too many changes in one
> shot. :-)
>
> >
> > [...]
> >
> > > Index: linux-2.6.22-rc3/Documentation/power/swsusp.txt
> > > ===================================================================
> > > --- linux-2.6.22-rc3.orig/Documentation/power/swsusp.txt
> > > +++ linux-2.6.22-rc3/Documentation/power/swsusp.txt
> > > @@ -140,22 +140,6 @@ should be sent to the mailing list avail
> > > website, and not to the Linux Kernel Mailing List. We are working
> > > toward merging suspend2 into the mainline kernel.
> > >
> > > -Q: A kernel thread must voluntarily freeze itself (call 'refrigerator').
> > > -I found some kernel threads that don't do it, and they don't freeze
> > > -so the system can't sleep. Is this a known behavior?
> > > -
> > > -A: All such kernel threads need to be fixed, one by one. Select the
> > > -place where the thread is safe to be frozen (no kernel semaphores
> > > -should be held at that point and it must be safe to sleep there), and
> > > -add:
> > > -
> > > - try_to_freeze();
> > > -
> > > -If the thread is needed for writing the image to storage, you should
> > > -instead set the PF_NOFREEZE process flag when creating the thread (and
> > > -be very careful).
> > > -
> > > -
> > > Q: What is the difference between "platform" and "shutdown"?
> > >
> > > A:
> >
> > Perhaps it would be good to keep a variant of this question, along the
> > lines of:
> >
> > Q: I have a kernel thread that needs to be frozen during hibernation.
> > How do I make that happen?
>
> Good idea.
>
> Thanks for the comments.
Glad to be of service!
Nigel
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-05-28 21:26 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-26 22:12 [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default Rafael J. Wysocki
2007-05-28 8:09 ` Rafael J. Wysocki
2007-05-28 10:30 ` Pavel Machek
2007-05-28 18:11 ` Rafael J. Wysocki
2007-05-28 9:46 ` Nigel Cunningham
2007-05-28 18:17 ` Rafael J. Wysocki
2007-05-28 21:26 ` Nigel Cunningham [this message]
2007-05-28 22:51 ` Rafael J. Wysocki
2007-05-28 22:54 ` Nigel Cunningham
2007-05-30 22:01 ` [RFC][PATCH -mm] Freezer: " Rafael J. Wysocki
2007-05-28 10:33 ` [RFC][PATCH][EXPERIMENTAL] " Pavel Machek
2007-05-28 18:11 ` Rafael J. Wysocki
2007-05-29 11:31 ` Pavel Machek
2007-05-29 12:15 ` Rafael J. Wysocki
2007-05-29 12:48 ` Pavel Machek
2007-05-29 21:55 ` Rafael J. Wysocki
2007-05-29 12:59 ` Nigel Cunningham
2007-05-29 22:13 ` Rafael J. Wysocki
2007-05-29 22:15 ` Nigel Cunningham
2007-05-29 15:01 ` Linus Torvalds
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=1180387582.4102.38.camel@nigel.suspend2.net \
--to=nigel@nigel.suspend2.net \
--cc=akpm@linux-foundation.org \
--cc=ego@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@tv-sign.ru \
--cc=pavel@ucw.cz \
--cc=rjw@sisk.pl \
--cc=torvalds@linux-foundation.org \
/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.