From: Rusty Russell <rusty@rustcorp.com.au>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: travis@sgi.com, mingo@redhat.com, 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: Wed, 4 Feb 2009 13:14:31 +1030 [thread overview]
Message-ID: <200902041314.32277.rusty@rustcorp.com.au> (raw)
In-Reply-To: <20090202200649.c1af2fd1.akpm@linux-foundation.org>
On Tuesday 03 February 2009 14:36:49 Andrew Morton wrote:
> But as you say, rdmsr_on_cpu() is easy to do, using
> smp_call_function_single(). Then we can easily convert all other
> work_on_cpu() callers to smp_call_function_single() and zap
> work_on_cpu(). The best outcome, methinks.
grepping for set_cpus_allowed reveals the following users in the
first third (when I got tired of it):
File Function Context Calls
powerpc/kernel/smp.c smp_cpus_done kernel_init smp_ops->setup_cpu()
x86/.../speedstep-ich.c _speedstep_get cpufreq speedstep_get_processor_frequency()
x86/.../powernow-k8.c check_supported_cpu cpufreq cpuid_*()
x86/.../powernow-k8.c powernowk8_target cpufreq mutex_lock, etc
x86/.../powernow-k8.c powernowk8_cpu_init boot/hotplg rdmsr,wrmsr
x86/.../powernow-k8.c powernowk8_get cpufreq rdmsr
x86/.../speedstep-centrino.c get_cur_freq cpufreq rdmsr
x86/.../speedstep-centrino.c centrino_target cpufreq rdmsr,wrmsr
x86/kernel/reboot.c nativ..._shutdown sys_reboot misc
x86/.../microcode_core.c do_microcode_update sys_write microcode_ops->request_microcode_user
x86/.../microcode_core.c reload_store sys_write mutex_lock, etc
Some of these (reboot) we don't care what they do to cpumask. Some are
poor style, but not critical (boot time). Some can use smp_call_function.
But there are some which should *not* be frobbing their cpus_allowed, and
really do seem to want a user context.
I think you're right though: smp_call_function_single (or neat wrappers)
where possible, work_on_cpu which can fail for the others, and we'll just
have to plumb in the error returns.
I'll start the patchstream for 2.6.30.
Thanks,
Rusty.
next prev parent reply other threads:[~2009-02-04 2:44 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
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 [this message]
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=200902041314.32277.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