Re: [PATCH 8/8] rhashtable: don't hold lock on first table throughout insertion.

2018-05-07 Thread NeilBrown
On Mon, May 07 2018, Herbert Xu wrote: > On Mon, May 07, 2018 at 08:24:41AM +1000, NeilBrown wrote: >> >> This is true, but I don't see how it is relevant. >> At some point, each thread will find that the table they have just >> locked for their search key, has a NULL 'future_tbl' pointer. >> At t

Re: [PATCH 8/8] rhashtable: don't hold lock on first table throughout insertion.

2018-05-07 Thread Herbert Xu
On Mon, May 07, 2018 at 08:24:41AM +1000, NeilBrown wrote: > > This is true, but I don't see how it is relevant. > At some point, each thread will find that the table they have just > locked for their search key, has a NULL 'future_tbl' pointer. > At the point, the thread can know that the key is n

Re: [PATCH 8/8] rhashtable: don't hold lock on first table throughout insertion.

2018-05-06 Thread NeilBrown
On Sun, May 06 2018, Herbert Xu wrote: > On Sun, May 06, 2018 at 08:00:49AM +1000, NeilBrown wrote: >> >> The insert function must (and does) take the lock on the bucket before >> testing if there is a "next" table. >> If one inserter finds that it has locked the "last" table (because there >> is

Re: [PATCH 8/8] rhashtable: don't hold lock on first table throughout insertion.

2018-05-05 Thread Herbert Xu
On Sun, May 06, 2018 at 08:00:49AM +1000, NeilBrown wrote: > > The insert function must (and does) take the lock on the bucket before > testing if there is a "next" table. > If one inserter finds that it has locked the "last" table (because there > is no next) and successfully inserts, then the oth

Re: [PATCH 8/8] rhashtable: don't hold lock on first table throughout insertion.

2018-05-05 Thread NeilBrown
On Sat, May 05 2018, Herbert Xu wrote: > On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote: >> rhashtable_try_insert() currently hold a lock on the bucket in >> the first table, while also locking buckets in subsequent tables. >> This is unnecessary and looks like a hold-over from some ear

Re: [PATCH 8/8] rhashtable: don't hold lock on first table throughout insertion.

2018-05-05 Thread Herbert Xu
On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote: > rhashtable_try_insert() currently hold a lock on the bucket in > the first table, while also locking buckets in subsequent tables. > This is unnecessary and looks like a hold-over from some earlier > version of the implementation. > > As

[PATCH 8/8] rhashtable: don't hold lock on first table throughout insertion.

2018-05-03 Thread NeilBrown
rhashtable_try_insert() currently hold a lock on the bucket in the first table, while also locking buckets in subsequent tables. This is unnecessary and looks like a hold-over from some earlier version of the implementation. As insert and remove always lock a bucket in each table in turn, and as i