[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150323000954.GB9507@gondor.apana.org.au>
Date: Mon, 23 Mar 2015 11:09:54 +1100
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Thomas Graf <tgraf@...g.ch>
Cc: "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <eric.dumazet@...il.com>,
Patrick McHardy <kaber@...sh.net>,
Josh Triplett <josh@...htriplett.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
netdev@...r.kernel.org
Subject: Re: [v2 PATCH 7/10] rhashtable: Disable automatic shrinking
On Sun, Mar 22, 2015 at 12:17:55PM +0000, Thomas Graf wrote:
>
> This is misleading. I agree that unconditional shrinking is dangerous.
> Shrinking was an optional feature disabled by default before. The
How was shrinking disabled before? AFAICS it always kicked in at
30%.
> inlining enabled it by default for all users. What is the benefit of
> requiring this logic outside of rhashtable over just adding a flag to
> enable shrinking at 30% utilization?
That would be adding an extra branch on the fast-path for an
operation which almost nobody needs.
> > int rhashtable_shrink(struct rhashtable *ht)
> > {
> > - struct bucket_table *new_tbl, *old_tbl = rht_dereference(ht->tbl, ht);
> > + unsigned size = roundup_pow_of_two(atomic_read(&ht->nelems) * 4 / 3);
>
> If rhashtable_shrink() is called near the 75% border it will cause an
> immediate expansion again. Maybe make this * 3 / 2 so we shrink near
> 30% utilization as before?
Sure that makes sense.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists