mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Gautham R Shenoy <ego@in.ibm.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Pavel Machek <pavel@ucw.cz>,
	Oleg Nesterov <oleg@tv-sign.ru>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFD] Freezing of kernel threads
Date: Sat, 12 May 2007 12:57:48 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.0.98.0705121241300.3986@woody.linux-foundation.org> (raw)
In-Reply-To: <20070512193609.GA31426@in.ibm.com>



On Sun, 13 May 2007, Gautham R Shenoy wrote:
> 
> With the "freeze-limited-kernel-threads" scheme, we would still need
> to perform this audit, since we now have to freeze only those kernel
> threads which *may* end up calling foo().

What the *heck* is wrong with just adding proper locking or other 
synchronization?

Why the hell do people think that they don't need locking for things?

In other words, you're just adding crap to make up for other crap. That's 
*not* how we do kernel develpment. I would seriously suggest people like 
that approach MS for a position on _their_ kernel team.

The fact is, if you want to avoid problems, you do so by having clear and 
clean approaches. THAT is how you avoid bugs. Not by adding crap.

I've several times suggested that if you actually want to stop the 
machine, you can do so at the scheduler level.

So stop talking about freezing when you're talkign abotu CPU hotplug. The 
two have _nothing_ to do with each other, and if there is something this 
whole discussion has absolutely convinced me about, it's that they will 
never have anything to do with each other.

If you worry about people doing 

	for_each_online_cpu()

in the presense of hotplug, here's a couple of simple solutions:

 - Just teach for_each_online_cpu() about locking. It's not a new concept. 
   We have it all over the kernel. 

   Maybe the macro itself can take whatever locks it needs, and maybe it's 
   as simple as a rule saying that: "you must hold spinlock XYZ when you 
   do that". But it has _nothing_ to do with freezing all threads.

 - make the rule be that you cannot sleep in the above macro, and make the 
   rule be that CPU hotplug uses the same mechanisms that module unload 
   already does!

In other words, we already have *better* mechanisms for cpu hotplug than 
the freezer. We have mechanisms that there is absolutely zero controversy 
about.

IOW, have you actually looked at "stop_machine_run()", which people use 
much more than the freezer, and which has never really caused any issues, 
and didn't result in us adding *crap* to every single kernel thread?

Really. The arguments for the freezer are CRAP. Why cannot people just 
admit it? We have *better* things available, that don't *need* any of this 
crap. The "stop_machine()" stuff literally ends up just running a 
high-priority thread on each CPU, and doesn't need any special support 
anywhere.

AND IT JUST WORKS. 

(Btw, I'm pretty sure it could be used for hibernation too: just stop the 
IO at a higher level first, sync, then stop_machine_run() etc. But I don't 
care. What I care about is that the freezer() insanity doesn't _spread_).

		Linus

  reply	other threads:[~2007-05-12 19:58 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-12 18:17 Rafael J. Wysocki
2007-05-12 18:25 ` Linus Torvalds
2007-05-12 21:14   ` Rafael J. Wysocki
2007-05-12 19:17 ` Pavel Machek
2007-05-12 19:40   ` Linus Torvalds
2007-05-12 22:14     ` Pavel Machek
2007-05-12 22:08   ` Rafael J. Wysocki
2007-05-12 19:36 ` Gautham R Shenoy
2007-05-12 19:57   ` Linus Torvalds [this message]
2007-05-12 20:11     ` Linus Torvalds
2007-05-13  8:33     ` Gautham R Shenoy
2007-05-13 16:33       ` Linus Torvalds
2007-05-13 20:08         ` Rafael J. Wysocki
2007-05-13 20:49           ` Linus Torvalds
2007-05-13 21:14             ` Rafael J. Wysocki
2007-05-14  6:18         ` Srivatsa Vaddagiri
2007-05-14  7:26           ` Gautham R Shenoy
2007-05-14 10:07             ` Rafael J. Wysocki
2007-05-14  7:41           ` Dipankar Sarma

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=alpine.LFD.0.98.0705121241300.3986@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --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 \
    /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

all inboxes | Powered by JetHome®