Herbert Xu <herb...@gondor.apana.org.au> wrote: > On Tue, Apr 25, 2017 at 01:23:56PM +0200, Florian Westphal wrote: > > > > What extra cost? > > > > The only change is that ht->nelems has to be right-shifted by one, > > I don't think that warrants extra space in struct rhashtable, its > > already way too large (I think we can reduce its size further). > > I see at least one hole on 64-bit which means that you can fit > it into struct rhashtable for free.
I'd rather close that hole by removing more stuff from rhastable and rhashtable_params structs instead. F.e. why do we need to have two key_len (one in params, one in struct rhashtable)? Or why does rhashtable use size_t in rhashtable_params to e.g. store a key offset? Just using 'unsigned int' instead would shrink rhashtable_params by 16 bytes. I'd have less of an issue with this if we'd be talking about something computationally expensive, but this is about storing an extra value inside a struct just to avoid one "shr" in insert path...
