[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [dm-devel] [PATCH v7 01/16] hashtable: introduce a small and naive hashtable
- From: Mathieu Desnoyers <mathieu desnoyers efficios com>
- To: Tejun Heo <tj kernel org>
- Cc: snitzer redhat com, fweisbec gmail com, Trond Myklebust netapp com, bfields fieldses org, paul gortmaker windriver com, dm-devel redhat com, agk redhat com, aarcange redhat com, rds-devel oss oracle com, eric dumazet gmail com, venkat x venkatsubra oracle com, ccaulfie redhat com, mingo elte hu, dev openvswitch org, jesse nicira com, josh joshtriplett org, rostedt goodmis org, teigland redhat com, Sasha Levin <levinsasha928 gmail com>, axboe kernel dk, linux-nfs vger kernel org, edumazet google com, linux-mm kvack org, netdev vger kernel org, linux-kernel vger kernel org, ejt redhat com, ebiederm xmission com, lw cn fujitsu com, akpm linux-foundation org, torvalds linux-foundation org, davem davemloft net
- Subject: Re: [dm-devel] [PATCH v7 01/16] hashtable: introduce a small and naive hashtable
- Date: Mon, 29 Oct 2012 12:22:21 -0400
* Tejun Heo (tj kernel org) wrote:
> Hello,
>
> On Mon, Oct 29, 2012 at 12:14:12PM -0400, Mathieu Desnoyers wrote:
> > Most of the calls to this initialization function apply it on zeroed
> > memory (static/kzalloc'd...), which makes it useless. I'd actually be in
> > favor of removing those redundant calls (as I pointed out in another
> > email), and document that zeroed memory don't need to be explicitly
> > initialized.
> >
> > Those sites that need to really reinitialize memory, or initialize it
> > (if located on the stack or in non-zeroed dynamically allocated memory)
> > could use a memset to 0, which will likely be faster than setting to
> > NULL on many architectures.
>
> I don't think it's a good idea to optimize out the basic encapsulation
> there. We're talking about re-zeroing some static memory areas which
> are pretty small. It's just not worth optimizing out at the cost of
> proper initializtion. e.g. We might add debug fields to list_head
> later.
Future-proofness for debugging fields is indeed a very compelling
argument. Fair enough!
We might want to document this intent at the top of the initialization
function though, just in case anyone want to short-circuit it.
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]