From: Tejun Heo <tj@kernel.org>
To: Gilad Ben-Yossef <gilad@benyossef.com>
Cc: linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
John Stultz <johnstul@us.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Mel Gorman <mel@csn.ul.ie>, Mike Frysinger <vapier@gentoo.org>,
David Rientjes <rientjes@google.com>,
Hugh Dickins <hughd@google.com>,
Minchan Kim <minchan.kim@gmail.com>,
Konstantin Khlebnikov <khlebnikov@openvz.org>,
Christoph Lameter <cl@linux.com>,
Chris Metcalf <cmetcalf@tilera.com>,
Hakan Akkan <hakanakkan@gmail.com>,
Max Krasnyansky <maxk@qualcomm.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
linux-mm@kvack.org
Subject: Re: [PATCH v1 3/6] workqueue: introduce schedule_on_each_cpu_cond
Date: Thu, 3 May 2012 08:39:41 -0700 [thread overview]
Message-ID: <20120503153941.GA5528@google.com> (raw)
In-Reply-To: <1336056962-10465-4-git-send-email-gilad@benyossef.com>
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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-05-03 15:39 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-03 14:55 [PATCH v1 0/6] reduce workqueue and timer noise Gilad Ben-Yossef
2012-05-03 14:55 ` [PATCH v1 1/6] timer: make __next_timer_interrupt explicit about no future event Gilad Ben-Yossef
2012-05-04 12:04 ` Frederic Weisbecker
2012-05-04 12:20 ` Frederic Weisbecker
2012-05-25 20:48 ` Thomas Gleixner
2012-05-25 20:56 ` Chris Metcalf
2012-05-25 21:04 ` Thomas Gleixner
2012-05-03 14:55 ` [PATCH v1 2/6] workqueue: introduce schedule_on_each_cpu_mask Gilad Ben-Yossef
2012-05-04 4:44 ` Srivatsa S. Bhat
2012-05-03 14:55 ` [PATCH v1 3/6] workqueue: introduce schedule_on_each_cpu_cond Gilad Ben-Yossef
2012-05-03 15:39 ` Tejun Heo [this message]
2012-05-06 13:15 ` Gilad Ben-Yossef
2012-05-07 17:17 ` Tejun Heo
2012-05-09 14:26 ` Gilad Ben-Yossef
2012-05-04 4:51 ` Srivatsa S. Bhat
2012-05-06 13:16 ` Gilad Ben-Yossef
2012-05-03 14:56 ` [PATCH v1 4/6] mm: make lru_drain selective where it schedules work Gilad Ben-Yossef
2012-05-03 14:56 ` [PATCH v1 5/6] mm: make vmstat_update periodic run conditional Gilad Ben-Yossef
2012-05-07 15:29 ` Christoph Lameter
2012-05-07 19:33 ` KOSAKI Motohiro
2012-05-07 19:40 ` Christoph Lameter
2012-05-08 15:25 ` Gilad Ben-Yossef
2012-05-08 15:34 ` Christoph Lameter
2012-05-09 14:26 ` Gilad Ben-Yossef
2012-05-08 15:22 ` Gilad Ben-Yossef
2012-05-08 15:18 ` Gilad Ben-Yossef
2012-05-08 15:24 ` Christoph Lameter
2012-05-03 14:56 ` [PATCH v1 6/6] x86: make clocksource watchdog configurable (not for mainline) Gilad Ben-Yossef
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=20120503153941.GA5528@google.com \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=cmetcalf@tilera.com \
--cc=fweisbec@gmail.com \
--cc=gilad@benyossef.com \
--cc=hakanakkan@gmail.com \
--cc=hughd@google.com \
--cc=johnstul@us.ibm.com \
--cc=khlebnikov@openvz.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=maxk@qualcomm.com \
--cc=mel@csn.ul.ie \
--cc=minchan.kim@gmail.com \
--cc=rientjes@google.com \
--cc=tglx@linutronix.de \
--cc=vapier@gentoo.org \
/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;
as well as URLs for NNTP newsgroup(s).