Thread (61 messages) 61 messages, 8 authors, 2012-10-29

Re: [PATCH v7 06/16] tracepoint: use new hashtable implementation

From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Date: 2012-10-29 19:10:46
Also in: dm-devel, linux-nfs, lkml, netdev

* Tejun Heo (tj@kernel.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

--
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/ .
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