public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Rusty Russell <rusty@rustcorp.com.au>
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: Tue, 3 Feb 2009 19:01:11 -0800	[thread overview]
Message-ID: <20090203190111.2ec31cef.akpm@linux-foundation.org> (raw)
In-Reply-To: <200902041314.32277.rusty@rustcorp.com.au>

On Wed, 4 Feb 2009 13:14:31 +1030 Rusty Russell <rusty@rustcorp.com.au> wrote:

> 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 bet a lot of those can use plain old schedule_work_on().

Could it be that after converting things to
smp_call_function_single()/schedule_work_on(), we don't need
work_on_cpu()?


  reply	other threads:[~2009-02-04  3:01 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
2009-02-04  3:01                                   ` Andrew Morton [this message]
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=20090203190111.2ec31cef.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=cpufreq@vger.kernel.org \
    --cc=davej@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rusty@rustcorp.com.au \
    --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