On Wed, Dec 12 2018, Herbert Xu wrote: > On Wed, Dec 12, 2018 at 05:41:29PM +1100, NeilBrown wrote: >> >> So you would substantially slow down the rhashtable_walk_start() step. > > This whole thing is meant for uses such as /proc and netlink > enumeration. Speed is definitely not a prerogative of these > iterators.
An RCU grace period is typically 10s of milliseconds. It doesn't take very many of those to start being noticed. > > For that matter, if speed was an issue then surely you would > not drop out of the RCU read lock at all while iterating. tipc_nl_sk_walk() drops out of RCU for every object. I don't know what it is used for, but I doubt that making it thousands of times slower would be a good thing. > > It sounds to me like you're trying to use this interface for > something that it's simply not designed to do. I'm just trying to make sure we have a reliable data structure which I can use without having to be worried that I might accidentally hit some unsupported behaviour. I don't really see why you think my patch is all that complex. The only conceptual change is that hash chains are now ordered, and ordered chains are easy to understand. The biggest part of the code change is just moving some code from rhashtable_walk_start() to rhashtable_walk_next(). Why don't you like it? Thanks, NeilBrown > > Cheers, > -- > Email: Herbert Xu <herb...@gondor.apana.org.au> > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
signature.asc
Description: PGP signature
