Re: [PATCH v7 06/16] tracepoint: use new hashtable implementation
From: Mathieu Desnoyers <hidden>
Date: 2012-10-29 19:10:46
Also in:
dm-devel, linux-mm, linux-nfs, lkml
From: Mathieu Desnoyers <hidden>
Date: 2012-10-29 19:10:46
Also in:
dm-devel, linux-mm, linux-nfs, lkml
* Tejun Heo (tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org) wrote:
On Mon, Oct 29, 2012 at 11:58:14AM -0700, Tejun Heo wrote:quoted
On Mon, Oct 29, 2012 at 02:53:19PM -0400, Mathieu Desnoyers wrote:quoted
The argument about hash_init being useful to add magic values in the future only works for the cases where a hash table is declared with DECLARE_HASHTABLE(). It's completely pointless with DEFINE_HASHTABLE(), because we could initialize any debugging variables from within DEFINE_HASHTABLE().You can do that with [0 .. HASH_SIZE - 1] initializer.And in general, let's please try not to do optimizations which are pointless. Just stick to the usual semantics. You have an abstract data structure - invoke the initializer before using it. Sure, optimize it if it shows up somewhere. And here, if we do the initializers properly, it shouldn't cause any more actual overhead - ie. DEFINE_HASHTABLE() will basicallly boil down to all zero assignments and the compiler will put the whole thing in .bss anyway.
Yes, agreed. I was going too far in optimization land by proposing assumptions on zeroed memory. All I actually really care about is that we don't end up calling hash_init() on a statically defined (and thus already initialized) hash table. Thanks, Mathieu -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com