[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZvYAzh1gEw3u5nyD@gondor.apana.org.au>
Date: Fri, 27 Sep 2024 08:48:14 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: Dave Chinner <david@...morbit.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-bcachefs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, Dave Chinner <dchinner@...hat.com>,
Thomas Graf <tgraf@...g.ch>, netdev@...r.kernel.org
Subject: Re: [GIT PULL] bcachefs changes for 6.12-rc1
On Tue, Sep 24, 2024 at 10:48:07PM -0400, Kent Overstreet wrote:
>
> I've been noticing rhashtable resize is surprisingly heavy (the default
> parameters don't ever shrink the table, which is why it's not seen as
> much).
Most rhashtable users enable automatic shrinking.
> And, when I was torture testing that code I tripped over what appeared
> to be an infinite loop in rht_bucket() when a rehsah is in progress,
> which I worked around in
>
> a592cdf5164d bcachefs: don't use rht_bucket() in btree_key_cache_scan()
You must not walk the rhashtable internal data structures by hand.
If you need to iterate through the whole table, use the provided
walking mechanism.
However, as rhashtable is dynamic, walking it during a resize may
cause you to see some elements twice. If you want to avoid that,
set up your own linked list of all elements for a completely stable
walk.
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