[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181214145632.urh3n4vua66wvmkx@gondor.apana.org.au>
Date: Fri, 14 Dec 2018 22:56:32 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Florian Westphal <fw@...len.de>
Cc: Wolfgang Walter <linux@...m.de>,
David Miller <davem@...emloft.net>,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
steffen.klassert@...unet.com, christophe.gouault@...nd.com
Subject: Re: INFO: rcu detected stall in xfrm_hash_rebuild
On Fri, Dec 14, 2018 at 03:35:32PM +0100, Florian Westphal wrote:
>
> Ok. An alternative would be to remove the support for
> policy hash table thresholds (which decide what kinds of policies
> go to exact table and which ones go into inexact ones), i.e.
> partially revert 880a6fab8f6ba5b5abe59ea6
> ("xfrm: configure policy hash table thresholds by netlink").
>
> This would remove the need for the rehashing support that
> re-sorts the policies into either exact/inexact lists) when the
> those tunables are changed.
>
> We could also easily convert the exact table to an rhashtable
> then if we wanted to.
We could also do both. In fact that was the reason why I started
working on rhashtable in the first place. The idea is to extend
the run-time rehashing to include both parts of the database.
So you would look up the old table/list combo and then move onto
the new one.
Of course I never had time to finish this and I think the entity
asking for this has moved onto something else.
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
Powered by blists - more mailing lists