On Fri, Aug 28, 2015 at 01:09:29PM +0200, Thomas Graf wrote: > On 08/28/15 at 12:28pm, Phil Sutter wrote: > > After adding cond_resched() calls to threadfunc(), a surprisingly high > > rate of insert failures occurred probably due to table resizes getting a > > better chance to run in background. To not soften up the remaining > > tests, retry inserts until they either succeed or fail permanently. > > > > Signed-off-by: Phil Sutter <p...@nwl.cc> > > --- > > lib/test_rhashtable.c | 13 +++++++------ > > 1 file changed, 7 insertions(+), 6 deletions(-) > > > > diff --git a/lib/test_rhashtable.c b/lib/test_rhashtable.c > > index 63654e3..093cf84 100644 > > --- a/lib/test_rhashtable.c > > +++ b/lib/test_rhashtable.c > > @@ -244,7 +244,7 @@ static int thread_lookup_test(struct thread_data *tdata) > > > > static int threadfunc(void *data) > > { > > - int i, step, err = 0, insert_fails = 0; > > + int i, step, err = 0, retries = 0; > > struct thread_data *tdata = data; > > > > up(&prestart_sem); > > @@ -253,21 +253,22 @@ static int threadfunc(void *data) > > > > for (i = 0; i < entries; i++) { > > tdata->objs[i].value = (tdata->id << 16) | i; > > +insert_retry: > > cond_resched(); > > err = rhashtable_insert_fast(&ht, &tdata->objs[i].node, > > test_rht_params); > > if (err == -ENOMEM || err == -EBUSY) { > > - tdata->objs[i].value = TEST_INSERT_FAIL; > > - insert_fails++; > > + retries++; > > + goto insert_retry; > > Is it safe to retry indefinitely on ENOMEM? Retrying on EBUSY is > definitely an improvement and we should do the same in the non > threaded test as well.
Oh yes, that is definitely a bug. I will respin and add the same for the normal test, too. Thanks, Phil -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html