lkml.org 
[lkml]   [2007]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFD] Freezing of kernel threads


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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-05-12 22:01    [W:0.078 / U:0.252 seconds]
©2003-2014 Jasper Spaans. Advertise on this site