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@xxxxxxxxx. 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@xxxxxxxxx";> email@xxxxxxxxx </a>