[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.0.98.0705130925290.6739@woody.linux-foundation.org>
Date: Sun, 13 May 2007 09:33:41 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Gautham R Shenoy <ego@...ibm.com>
cc: "Rafael J. Wysocki" <rjw@...k.pl>, Pavel Machek <pavel@....cz>,
Oleg Nesterov <oleg@...sign.ru>,
Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Dipankar Sarma <dipankar@...ibm.com>,
Ingo Molnar <mingo@...e.hu>,
Srivatsa Vaddagiri <vatsa@...ibm.com>,
Paul E McKenney <paulmck@...ibm.com>
Subject: Re: [RFD] Freezing of kernel threads
On Sun, 13 May 2007, Gautham R Shenoy wrote:
>
> RFC #1: Use get_hot_cpus()- put_hot_cpus() , which follow the
> well known refcounting model.
Yes. And usign the "preempt count" as a refcount is fairly natural, no?
We do already depend on that in many code-paths.
It also has the advantage since it's not a *blocking* lock, it's fairly
easy to code around (ie since it nests, it avoids the kinds of nasty
deadlocks we had with cpufreq that had totally insane calling semantics
and different people all wanted the lock).
Of course, a real nesting lock could be used to the same effect.
> RFC #1 and #2 DO work. But, the discussions in the thread
> http://lkml.org/lkml/2007/1/26/282 gave me the impression
> that we would be better off without any code audits to
> make the code paths cpu-hotplug safe. I would leave it for others
> to shed more light here.
Well, I hope that _this_ discussion about the freezer has convinced you
that there are no more fundamntal problems with #1/#2 than with using the
freezer.
The freezer really needs even *more* code auditing, since it's almost
impossible to see which thread depends on some other thread. There's a
real reason why most kernel threads disable freezing.
At least with locking, the code-paths you require to audit are all
actually relevant to cpu hotplug, and you can easily add dynamic
_automated_ tests like "if you use online_cpu_map, you'd better hold the
preempt lock".
For example, since all users of cpu_online_map should be pure *readers*
(apart from a couple of cases that actually bring up a CPU), you can do
things like
#define cpu_online_map check_cpu_online_map()
static inline cpumask_t check_cpu_online_map(void)
{
WARN_ON(!preempt_safe()); /* or whatever lock we decide on */
return __real_cpu_online_map;
}
and it will nicely catch things like that.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists