From: Florian Westphal
Date: Tue, 25 Apr 2017 11:41:34 +0200
> no users in the tree, insecure_max_entries is always set to
> ht->p.max_size * 2 in rhtashtable_init().
>
> Replace only spot that uses it with a ht->p.max_size check.
>
> Signed-off-by: Florian Westphal
Applied, thanks Florian.
From: Florian Westphal
Date: Tue, 25 Apr 2017 16:17:49 +0200
> 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...
Agreed, this shift is probably f
Herbert Xu 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
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
Herbert Xu wrote:
> Florian Westphal wrote:
> > no users in the tree, insecure_max_entries is always set to
> > ht->p.max_size * 2 in rhtashtable_init().
> >
> > Replace only spot that uses it with a ht->p.max_size check.
>
> I'd suggest that as this needs to be computed every time we insert
>
Florian Westphal wrote:
> no users in the tree, insecure_max_entries is always set to
> ht->p.max_size * 2 in rhtashtable_init().
>
> Replace only spot that uses it with a ht->p.max_size check.
I'd suggest that as this needs to be computed every time we insert
an element that you keep the value
