On Mon, 2 Feb 2009 23:05:50 +1030 Rusty Russell <rusty@xxxxxxxxxxxxxxx> wrote:
> +/**
> + * __work_on_cpu - run a function in a workqueue on a particular cpu
> + * @swq: the (singlethreaded) workqueue
> + * @cpu: the cpu to run on
> + * @fn: the function to run
> + * @arg: the function arg
> + *
> + * This will return the value @fn returns.
> + * It is up to the caller to ensure that the cpu doesn't go offline.
> + *
> + * Example:
> + * int ret;
> + * struct workqueue_struct *wq = create_singlethread_workqueue("myq");
> + * if (unlikely(!wq))
> + * ret = -ENOMEM;
> + * else {
> + * ret = __work_on_cpu(wq, cpu, fn, arg);
> + * destroy_workqueue(wq);
> + * }
> + */
> +long __work_on_cpu(struct workqueue_struct *swq,
> + unsigned int cpu, long (*fn)(void *), void *arg)
> +{
> + struct work_for_cpu wfc;
> +
> + INIT_WORK(&wfc.work, do_work_for_cpu);
> + wfc.fn = fn;
> + wfc.arg = arg;
> + wfc.cpu = cpu;
> + BUG_ON(!swq->singlethread);
> + queue_work(swq, &wfc.work);
> + flush_work(&wfc.work);
> +
> + return wfc.ret;
> +}
> +EXPORT_SYMBOL_GPL(__work_on_cpu);
If we're going to do this then we might as well create the thread right
here, use it once and then let it exit.
That's slower, but I suspect that we could get a lot of that inefficiency
back by coming up with a kernel_thread_on_cpu(), so we don't go and schedule
the function on a random CPU only to immediately switch it over to a different
one, dunno.
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.
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
