linux-kernel - Re: [PATCH v1 3/6] workqueue: introduce schedule_on_each_cpu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120507171725.GB19417@google.com>
Date:	Mon, 7 May 2012 10:17:25 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Gilad Ben-Yossef <gilad@...yossef.com>
Cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	John Stultz <johnstul@...ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Mel Gorman <mel@....ul.ie>, Mike Frysinger <vapier@...too.org>,
	David Rientjes <rientjes@...gle.com>,
	Hugh Dickins <hughd@...gle.com>,
	Minchan Kim <minchan.kim@...il.com>,
	Konstantin Khlebnikov <khlebnikov@...nvz.org>,
	Christoph Lameter <cl@...ux.com>,
	Chris Metcalf <cmetcalf@...era.com>,
	Hakan Akkan <hakanakkan@...il.com>,
	Max Krasnyansky <maxk@...lcomm.com>,
	Frederic Weisbecker <fweisbec@...il.com>, linux-mm@...ck.org
Subject: Re: [PATCH v1 3/6] workqueue: introduce schedule_on_each_cpu_cond

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/