public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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 --]

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox