From: Rusty Russell <rusty@rustcorp.com.au>
To: Mike Travis <travis@sgi.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@redhat.com>, Dave Jones <davej@redhat.com>,
cpufreq@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
Date: Thu, 29 Jan 2009 21:09:23 +1030 [thread overview]
Message-ID: <200901292109.24160.rusty@rustcorp.com.au> (raw)
In-Reply-To: <498096BA.2000301@sgi.com>
On Thursday 29 January 2009 04:02:42 Mike Travis wrote:
> Mike Travis wrote:
> > Hi Rusty,
> >
> > I'm testing this now on x86_64 and one question comes up. The
> > initialization of the woc_wq thread happens quite late. Might it
> > be better to initialize it earlier?
>
> Umm, definitely needed earlier... A bug catcher caught this. Work_on_cpu
> is being called before it's initialized.
>
> [ 16.541297] calling microcode_init+0x0/0x13a @ 1
OK, core_initcall will be sufficient to call before this one.
I also want to change the code so that the affinity is set from work_on_cpu rather than the thread itself; it's slightly more efficient.
Here's a patch-on-top.
work_on_cpu: bug fix and enhancements
Make it a core_initcall, since a module_initcall needs it.
Also, make the caller set the affinity of the worker thread: this is
more efficient than setting our own affinity (which requires the
migration thread's help).
This has two side effects:
1) We will oops if work_on_cpu is called too early,
2) We can WARN_ON and just run on the wrong cpu rather than locking up if
they ask for an offline cpu (bug compatible old method of calling
set_cpus_allowed).
Test code exercises WARN_ON; you probably want to remove it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
diff --git a/kernel/work_on_cpu.c b/kernel/work_on_cpu.c
--- a/kernel/work_on_cpu.c
+++ b/kernel/work_on_cpu.c
@@ -5,6 +5,10 @@
#include <linux/cpumask.h>
#include <linux/module.h>
+#define DEBUG
+
+/* The thread which actually does the work. */
+static struct task_struct *woc_thread;
/* The thread waits for new work on this waitqueue. */
static DECLARE_WAIT_QUEUE_HEAD(woc_wq);
/* The lock ensures only one job is done at a time. */
@@ -12,7 +16,9 @@ static DEFINE_MUTEX(woc_mutex);
/* The details of the current job. */
struct work_for_cpu {
+#ifdef DEBUG
unsigned int cpu;
+#endif
long (*fn)(void *);
void *arg;
long ret;
@@ -33,8 +39,9 @@ static int do_work_on_cpu(void *unused)
wait_event(woc_wq, current_work != NULL);
- set_cpus_allowed_ptr(current, cpumask_of(current_work->cpu));
+#ifdef DEBUG
WARN_ON(smp_processor_id() != current_work->cpu);
+#endif
current_work->ret = current_work->fn(current_work->arg);
/* Make sure ret is set before we complete(). Paranoia. */
@@ -62,12 +69,21 @@ long work_on_cpu(unsigned int cpu, long
{
struct work_for_cpu work;
+#ifdef DEBUG
work.cpu = cpu;
+#endif
work.fn = fn;
work.arg = arg;
init_completion(&work.done);
mutex_lock(&woc_mutex);
+ if (set_cpus_allowed_ptr(woc_thread, cpumask_of(cpu)) != 0) {
+ WARN(1, "work_on_cpu on offline cpu %i?\n", cpu);
+#ifdef DEBUG
+ /* Avoids the additional WARN_ON in the thread. */
+ work.cpu = task_cpu(woc_thread);
+#endif
+ }
/* Make sure all is in place before it sees fn set. */
wmb();
current_work = &work;
@@ -81,7 +97,7 @@ long work_on_cpu(unsigned int cpu, long
}
EXPORT_SYMBOL_GPL(work_on_cpu);
-#if 1
+#ifdef DEBUG
static long test_fn(void *arg)
{
printk("%u: %lu\n", smp_processor_id(), (long)arg);
@@ -93,16 +109,16 @@ static int __init init(void)
{
unsigned int i;
- kthread_run(do_work_on_cpu, NULL, "kwork_on_cpu");
+ woc_thread = kthread_run(do_work_on_cpu, NULL, "kwork_on_cpu");
-#if 1
- for_each_online_cpu(i) {
+#ifdef DEBUG
+ for_each_possible_cpu(i) {
long ret = work_on_cpu(i, test_fn, (void *)i);
printk("CPU %i returned %li\n", i, ret);
- BUG_ON(ret != i + 100);
+ BUG_ON(cpu_online(i) && ret != i + 100);
}
#endif
return 0;
}
-module_init(init);
+core_initcall(init);
next prev parent reply other threads:[~2009-01-29 10:39 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-16 19:11 [PATCH 0/3] cpu freq: fix problems with work_on_cpu usage in acpi-cpufreq Mike Travis
2009-01-16 19:11 ` [PATCH 1/3] work_on_cpu: dont try to get_online_cpus() in work_on_cpu Mike Travis
2009-01-16 19:11 ` [PATCH 2/3] work_on_cpu: Use our own workqueue Mike Travis
2009-01-24 8:15 ` Andrew Morton
[not found] ` <200901261711.43943.rusty@rustcorp.com.au>
2009-01-26 7:01 ` Andrew Morton
2009-01-26 17:16 ` Ingo Molnar
2009-01-26 18:35 ` Andrew Morton
2009-01-26 20:20 ` Ingo Molnar
2009-01-26 20:43 ` Mike Travis
2009-01-26 21:00 ` Andrew Morton
2009-01-26 21:27 ` Ingo Molnar
2009-01-26 21:35 ` Andrew Morton
2009-01-26 21:45 ` Ingo Molnar
2009-01-26 22:01 ` Andrew Morton
2009-01-26 22:05 ` Ingo Molnar
2009-01-26 22:16 ` Andrew Morton
2009-01-26 22:20 ` Ingo Molnar
2009-01-26 22:50 ` Andrew Morton
2009-01-26 22:59 ` Ingo Molnar
2009-01-26 23:42 ` Andrew Morton
2009-01-26 23:53 ` Ingo Molnar
2009-01-27 0:42 ` Andrew Morton
2009-01-26 22:31 ` Oleg Nesterov
2009-01-26 22:15 ` Oleg Nesterov
2009-01-26 22:24 ` Ingo Molnar
2009-01-26 22:37 ` Oleg Nesterov
2009-01-26 22:42 ` Ingo Molnar
2009-01-26 21:50 ` Oleg Nesterov
2009-01-26 22:17 ` Ingo Molnar
2009-01-26 23:01 ` Mike Travis
2009-01-27 0:09 ` Oleg Nesterov
2009-01-27 7:15 ` Rusty Russell
2009-01-27 17:55 ` Oleg Nesterov
2009-01-27 7:05 ` Rusty Russell
2009-01-27 7:25 ` Andrew Morton
2009-01-27 15:28 ` Ingo Molnar
2009-01-27 16:51 ` Andrew Morton
2009-01-28 13:02 ` Rusty Russell
2009-01-28 17:19 ` Mike Travis
2009-01-28 17:32 ` Mike Travis
2009-01-29 10:39 ` Rusty Russell [this message]
2009-01-28 19:44 ` Andrew Morton
2009-01-29 1:43 ` Rusty Russell
2009-01-29 2:12 ` Andrew Morton
2009-01-30 6:03 ` Rusty Russell
2009-01-30 6:30 ` Andrew Morton
2009-01-30 13:49 ` Ingo Molnar
2009-01-30 17:08 ` Andrew Morton
2009-01-30 21:59 ` Rusty Russell
2009-01-30 22:17 ` Andrew Morton
2009-02-02 12:35 ` Rusty Russell
2009-02-03 4:06 ` Andrew Morton
2009-02-04 2:44 ` Rusty Russell
2009-02-04 3:01 ` Andrew Morton
2009-02-04 10:41 ` Rusty Russell
2009-02-04 15:36 ` Andrew Morton
2009-02-04 21:35 ` Ingo Molnar
2009-02-04 21:48 ` Andrew Morton
2009-02-04 21:54 ` Ingo Molnar
2009-02-04 23:45 ` Rusty Russell
2009-02-05 12:19 ` Pavel Machek
2009-02-05 17:44 ` Dmitry Adamushko
2009-02-10 8:54 ` Rusty Russell
2009-02-10 9:35 ` Andrew Morton
2009-02-11 0:32 ` Rusty Russell
2009-01-16 19:11 ` [PATCH 3/3] cpufreq: use work_on_cpu in acpi-cpufreq.c for drv_read and drv_write Mike Travis
2009-01-16 23:38 ` [PATCH 0/3] cpu freq: fix problems with work_on_cpu usage in acpi-cpufreq [PULL request] Mike Travis
2009-01-17 22:08 ` Ingo Molnar
2009-01-19 17:11 ` Mike Travis
2009-01-19 17:26 ` Ingo Molnar
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=200901292109.24160.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=akpm@linux-foundation.org \
--cc=cpufreq@vger.kernel.org \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=travis@sgi.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.