public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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);

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox