Received: by 10.213.65.68 with SMTP id h4csp113980imn; Tue, 27 Mar 2018 23:26:21 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+TbHxWFgo2lfHvjlmgqr5iO1v8zhNsF4aSWydC0fXaCBmWBUv1/24XrGzcawTNGILcZIj+ X-Received: by 10.101.81.75 with SMTP id g11mr1638033pgq.143.1522218381492; Tue, 27 Mar 2018 23:26:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522218381; cv=none; d=google.com; s=arc-20160816; b=lIzbDX8OgDPR/bVUOn5X2XUVTSC1OFK/bTmfuJ2oZvOx8eaROiA30cufQXwUIp6jV1 m7XpgWIbV4S8MBdqJREVqh6BfYHOgkOIiw8NygN/h5pzOHnnDA7xBjAKNBu3A/7axAzn pNpi5ODoeH+S5bfqIoVXPiIomkV2WwRh59A/GVA0AE3WnJHycM3hpbLF6T5UqLbdRG2o eQZSH0GJMYKRwis9bCbk/tXQIsSQZRljQtESYlFMiN1N6tdiHZBqhvE3f/W6ZpYTc64q C3f0ZFo510qg5tKYW5ZA7fqTj5Lax1iZwE8YbxggN3RwqECKy3lT0qYDQ53JnyEm7f6Q UcNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=IDOf40Y/KicDZ7aSWoayQOr5lfnVXUXpbstvvNqSyco=; b=qhx1XieSUomsYPKrOvF1yrOJ5mQ2CJALGqRUqNmZCsx73XKUtB1ofZdQga2F/Skbtl +FhVkWGl0HJbr407psqwRbmBK2dhoNoae0vlxI/7oajwmkb1xZ2LzdK5wkPF66302FBj RvJyp7g1tTYSHqMgfTdQjMA69+edpL4gjpcLrDonjQeChv8s0bIBBsCM9Mr1y0X/QL0y xnC0eTKO/YT6kJ7Ckk3xtS2WINJ2gr6i2L+9gWVQuUieLHDSFpxJgO9I+BnilkJX6OsM cgB/ZKEu1tGRk03eeoagdMwYb6dyTC62IiEA1wSFDECl5evUMmNTP3Kk0huLIiTRMu1m J7dw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 13-v6si2804641plb.515.2018.03.27.23.26.07; Tue, 27 Mar 2018 23:26:21 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751994AbeC1GEo (ORCPT + 99 others); Wed, 28 Mar 2018 02:04:44 -0400 Received: from orcrist.hmeau.com ([104.223.48.154]:46528 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751147AbeC1GEn (ORCPT ); Wed, 28 Mar 2018 02:04:43 -0400 Received: from gondobar.mordor.me.apana.org.au ([192.168.128.4] helo=gondobar) by deadmen.hmeau.com with esmtp (Exim 4.84_2 #2 (Debian)) id 1f14CJ-0006g7-Gf; Wed, 28 Mar 2018 14:04:35 +0800 Received: from herbert by gondobar with local (Exim 4.84_2) (envelope-from ) id 1f14CG-0004HW-3P; Wed, 28 Mar 2018 14:04:32 +0800 Date: Wed, 28 Mar 2018 14:04:32 +0800 From: Herbert Xu To: NeilBrown Cc: Thomas Graf , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 5/6] rhashtable: support guaranteed successful insertion. Message-ID: <20180328060432.GA16291@gondor.apana.org.au> References: <152210688405.11435.13010923693146415942.stgit@noble> <152210718434.11435.6551477417902631683.stgit@noble> <20180327155610.GD14001@gondor.apana.org.au> <87y3id42zo.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87y3id42zo.fsf@notabene.neil.brown.name> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 28, 2018 at 08:34:19AM +1100, NeilBrown wrote: > > It is easy to get an -EBUSY insertion failure when .disable_count is > enabled, and I did get that. Blindly propagating that up caused lustre > to get terribly confused - not too surprising really. Right, so this failure mode is specific to your patch 6. I think I see the problem. As it currently stands, we never need growing when we hit the bucket length limit. We only do rehashes. With your patch, you must change it so that we actually try to grow the table if necessary when we hit the bucket length limit. Otherwise it will result in the EBUSY that you're seeing. I laso think that we shouldn't make this a toggle. If we're going to do disable_count then it should be unconditionally done for everyone. However, I personally would prefer a percpu elem count instead of disabling it completely. Would that be acceptable to your use-case? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt