Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751872AbbH1LJd (ORCPT ); Fri, 28 Aug 2015 07:09:33 -0400 Received: from mail-wi0-f180.google.com ([209.85.212.180]:38107 "EHLO mail-wi0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751445AbbH1LJb (ORCPT ); Fri, 28 Aug 2015 07:09:31 -0400 Date: Fri, 28 Aug 2015 13:09:29 +0200 From: Thomas Graf To: Phil Sutter Cc: davem@davemloft.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, fengguang.wu@intel.com, wfg@linux.intel.com, lkp@01.org Subject: Re: [PATCH 2/3] rhashtable-test: retry insert operations in threads Message-ID: <20150828110929.GI32206@pox.localdomain> References: <1440757685-14241-1-git-send-email-phil@nwl.cc> <1440757685-14241-2-git-send-email-phil@nwl.cc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1440757685-14241-2-git-send-email-phil@nwl.cc> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1758 Lines: 46 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 > --- > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/