All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Gautham R Shenoy <ego@in.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Davide Libenzi <davidel@xmailserver.org>,
	Jan Engelhardt <jengelh@linux01.gwdg.de>,
	Ingo Molnar <mingo@elte.hu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Robin Holt <holt@sgi.com>, Roland McGrath <roland@redhat.com>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	linux-kernel@vger.kernel.org, vatsa@in.ibm.com
Subject: Re: [PATCH] kthread: Don't depend on work queues
Date: Wed, 11 Apr 2007 21:37:21 +0200	[thread overview]
Message-ID: <200704112137.22758.rjw@sisk.pl> (raw)
In-Reply-To: <20070411143626.GA125@tv-sign.ru>

On Wednesday, 11 April 2007 16:36, Oleg Nesterov wrote:
> On 04/11, Gautham R Shenoy wrote:
> > On Wed, Apr 11, 2007 at 03:48:05PM +0400, Oleg Nesterov wrote:
> > > On 04/11, Gautham R Shenoy wrote:
> > > >
> > > > On Wed, Apr 11, 2007 at 12:13:34PM +0200, Rafael J. Wysocki wrote:
> > > > > 
> > > > > It should be calling try_to_freeze() somewhere anyway.  We may need to freeze
> > > > > all tasks in some cases.
> > > > 
> > > > How about
> > > > for (;;) {
> > > > 	try_to_freeze();
> > > > 
> > > > ?
> > > 
> > > Why?
> > 
> > If some event (defintely NOT cpu hotplug) needs this thread frozen.
> > 
> > > 
> > > > This change allows us to make all the worker threads freezeable by default.
> > > > >From cpu-hotplug perspective, helper_wq was the only singlethreaded
> > > > non-freezeable workqueue.
> > > 
> > > I think Eric's patch is what you need. We should _not_ freeze kthreadd(), we
> > > need kthread_create() after freezing. Now it doesn't depend on workqueues, we
> > > can freeze them all, single-thread or not.
> > > 
> > 
> > These were my exact thoughts. 
> 
> Sorry, I misunderstood your message.
> 
> Yes, we can freeze it with FE_HOTPLUG_CPU. In that case wait_event()
> should also check !freezing(), and try_to_freeze() should be called
> after case wait_event().
> 
> On the other hand, if "kthreadd" does not sleep on kthread_create_work,
> we have another unfrozen process waiting for kthread_create_info.done.
> So, is there any practical reason why kthreadd() should explicitely go
> to refrigerator?

Good question.  Right now, there probably is not any.

Greetings,
Rafael

  reply	other threads:[~2007-04-11 19:33 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-10 18:51 [PATCH 2/3] make kernel threads invisible to /sbin/init Oleg Nesterov
2007-04-10 23:16 ` Serge E. Hallyn
2007-04-11  3:29   ` Eric W. Biederman
2007-04-11  3:56 ` Eric W. Biederman
2007-04-11 11:42   ` Oleg Nesterov
2007-04-11  5:44 ` [PATCH] kthread: Don't depend on work queues Eric W. Biederman
2007-04-11  7:03   ` Andrew Morton
2007-04-11 10:13     ` Rafael J. Wysocki
2007-04-11 11:21       ` Gautham R Shenoy
2007-04-11 11:48         ` Oleg Nesterov
2007-04-11 13:31           ` Gautham R Shenoy
2007-04-11 14:36             ` Oleg Nesterov
2007-04-11 19:37               ` Rafael J. Wysocki [this message]
2007-04-11 14:44             ` Rafael J. Wysocki
2007-04-11 18:22     ` Eric W. Biederman
2007-04-11 18:27     ` [PATCH] kthread: Don't depend on work queues (take 2) Eric W. Biederman
2007-04-11 18:49       ` [PATCH] Change reparent_to_init to reparent_to_kthreadd Eric W. Biederman
2007-04-11 19:21       ` [PATCH] kthread: Don't depend on work queues (take 2) Andrew Morton
2007-04-11 19:28       ` Oleg Nesterov
2007-04-11 19:40         ` Eric W. Biederman
2007-04-11 19:49           ` Oleg Nesterov
2007-04-11 20:02             ` Eric W. Biederman
2007-04-11 12:04   ` [PATCH] kthread: Don't depend on work queues Oleg Nesterov
2007-04-11 16:25     ` Eric W. Biederman
2007-04-11 13:15   ` Oleg Nesterov
2007-04-11 16:22     ` Eric W. Biederman

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=200704112137.22758.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=akpm@linux-foundation.org \
    --cc=davidel@xmailserver.org \
    --cc=ebiederm@xmission.com \
    --cc=ego@in.ibm.com \
    --cc=holt@sgi.com \
    --cc=jengelh@linux01.gwdg.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@tv-sign.ru \
    --cc=roland@redhat.com \
    --cc=serge@hallyn.com \
    --cc=torvalds@linux-foundation.org \
    --cc=vatsa@in.ibm.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.