Thread (28 messages) 28 messages, 8 authors, 2012-05-25

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

From: Tejun Heo <tj@kernel.org>
Date: 2012-05-07 17:17:32
Also in: lkml

Hello,

On Sun, May 06, 2012 at 04:15:30PM +0300, Gilad Ben-Yossef wrote:
A single helper function called schedule_on_each_cpu_cond() is very
obvious to find to someone reading the source or documentation. On
the other hand figuring out that the helper functions that handle
cpu hotplug and cpumask allocation are there for that purpose is a
bit more involved.

That was my thinking at least.
Yeah, having common mechanism is nice, but I just prefer iterators /
helpers which can be embedded in the caller to interface which takes a
callback unless the execution context is actually asynchronous to the
caller.  We don't use nested functions / scopes in kernel which makes
those callbacks (higher order functions, lambdas, gammas, zetas
whatever) painful to use and follow.
The way i see it, I can either obliterate on_each_cpu_cond() and out
its code in place in the LRU path, or fix the callback to get an
extra private data parameter -
Unless we can code up something pretty, I vote for just open coding it
for now.  If we grow more usages like this, maybe we'll be able to see
the pattern better and come up with better abstraction.

Thank you.

-- 
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>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help