Re: [PATCH v1 3/6] workqueue: introduce schedule_on_each_cpu_cond

From: Tejun Heo
Date: Thu May 03 2012 - 11:39:43 EST


Hello,

On Thu, May 03, 2012 at 05:55:59PM +0300, Gilad Ben-Yossef wrote:
> Introduce the schedule_on_each_cpu_cond() function that schedules
> a work item on each online CPU for which the supplied condition
> function returns true.
>
> This function should be used instead of schedule_on_each_cpu()
> when only some of the CPUs have actual work to do and a predicate
> function can tell if a certain CPU does or does not have work to do,
> thus saving unneeded wakeups and schedules.
>
> /**
> + * schedule_on_each_cpu_cond - execute a function synchronously on each
> + * online CPU for which the supplied condition function returns true
> + * @func: the function to run on the selected CPUs
> + * @cond_func: the function to call to select the CPUs
> + *
> + * schedule_on_each_cpu_cond() executes @func on each online CPU for
> + * @cond_func returns true using the system workqueue and blocks until
> + * all CPUs have completed.
> + * schedule_on_each_cpu_cond() is very slow.
> + *
> + * RETURNS:
> + * 0 on success, -errno on failure.
> + */
> +int schedule_on_each_cpu_cond(work_func_t func, bool (*cond_func)(int cpu))
> +{
> + int cpu, ret;
> + cpumask_var_t mask;
> +
> + if (unlikely(!zalloc_cpumask_var(&mask, GFP_KERNEL)))
> + return -ENOMEM;
> +
> + get_online_cpus();
> +
> + for_each_online_cpu(cpu)
> + if (cond_func(cpu))
> + cpumask_set_cpu(cpu, mask);
> +
> + ret = schedule_on_each_cpu_mask(func, mask);
> +
> + put_online_cpus();
> +
> + free_cpumask_var(mask);
> +
> + return ret;
> +}

I'm usually not a big fan of callback based interface. They tend to
be quite clunky to use. e.g. in this case, wouldn't it be better to
have helper functions which allocate cpumask and disables cpu hotplug
and undo that afterwards? That is, if such convenience helpers are
necessary at all. Also, callback which doesn't have a private data
argument tends to be PITA.

Thanks.

--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/