Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3681506imm; Tue, 29 May 2018 11:30:12 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrsaraNH6XhuY+0WQA/0Rlz29EMtnVb9ALShxCIIFvuDtnr2REKIsBQ0e/JCrwaXsw9zgwF X-Received: by 2002:a62:f58b:: with SMTP id b11-v6mr18406787pfm.113.1527618612727; Tue, 29 May 2018 11:30:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527618612; cv=none; d=google.com; s=arc-20160816; b=kJbJNlhivCRvzQk3ChhThaKECLNYg/oVdrfVp4Y6Di/6xJWbMVfDyUfOWHjyici+CF McWbVHj//vQTNjkjd+s0AGX94ygnfHi5xlQMlYYzB3gwSQGLDK5hQs/7TuCekXFiNTF5 QronRDdM0L+FDtfzsgNxLPILAW5cndXUnFQqto4a1kDTsB/1VQa/9Rej1h0ry8tG9zoD MGSFtuxGT2BMXdyV7g8WAynlQtcBrMu9KkstFR81RoQQL6iDZ1QK2cWnBvVekT7oRxl6 RQXeNI0hJE2ylHroSQkYclyeu1t/Pv8E7xeLKMe0qMT+QCtCjv3elple8C+ewF544cVV xLfw== 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=yEbLqL9qqRbs0JGSpEgJzrPQpGLVJcAqkbt5VmbPkOU=; b=IW1mo6I9tjD/pRkaC4WtrT9++5z5/zk7gprsPgPSdF+yYEG/DnjGpXCOAF3eDgFl2L 4Ftbfpc+SZf2SIj29rHJROAvM2aa0wZJTR8Hyr3pFUuHmJ64+FUUm6ifejC7hSMOK4ZG 8VGwrM8WcBYV9UcDxUE14QO/hWP2nvqYU5OKa0g0oUQNCUtW4OPiG/6SIUwoNWsU3jor VrWKy2Wl+l5XVOJRz5LjPhjXG/SVPLbs3CKRNIS11WIgykgMQRpX1v8TtvvtfuEzBy4T xRzmgy9ghOf7N/jm7ex/dYXKUjTL9Uj82yF5aPwlqAnBcRkPunuVu/MpjvAlTo3pUrbR uhCw== 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 u10-v6si25725883pgr.642.2018.05.29.11.29.58; Tue, 29 May 2018 11:30:12 -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 S966334AbeE2S2D (ORCPT + 99 others); Tue, 29 May 2018 14:28:03 -0400 Received: from orcrist.hmeau.com ([104.223.48.154]:45806 "EHLO deadmen.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965960AbeE2S2A (ORCPT ); Tue, 29 May 2018 14:28:00 -0400 Received: from gondobar.mordor.me.apana.org.au ([192.168.128.4] helo=gondobar) by deadmen.hmeau.com with esmtps (Exim 4.89 #2 (Debian)) id 1fNjLY-0003zO-OK; Wed, 30 May 2018 02:27:48 +0800 Received: from herbert by gondobar with local (Exim 4.89) (envelope-from ) id 1fNjLW-0006TB-6G; Wed, 30 May 2018 02:27:46 +0800 Date: Wed, 30 May 2018 02:27:46 +0800 From: Herbert Xu To: Davidlohr Bueso Cc: akpm@linux-foundation.org, torvalds@linux-foundation.org, tgraf@suug.ch, manfred@colorfullife.com, guillaume.knispel@supersonicimagine.com, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, Davidlohr Bueso Subject: Re: [PATCH 2/6] lib/rhashtable: guarantee initial hashtable allocation Message-ID: <20180529182746.t4b7tsnfma7dupom@gondor.apana.org.au> References: <20180524211135.27760-1-dave@stgolabs.net> <20180524211135.27760-3-dave@stgolabs.net> <20180528094956.zaxusqqju3wtbdcz@gondor.apana.org.au> <20180529170338.7brp2m2k4gfqwf64@linux-n805> <20180529180428.l6yt6ae4oxbgrja6@gondor.apana.org.au> <20180529175927.iyea653hpgnow6p2@linux-n805> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180529175927.iyea653hpgnow6p2@linux-n805> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 29, 2018 at 10:59:27AM -0700, Davidlohr Bueso wrote: > On Wed, 30 May 2018, Herbert Xu wrote: > > > It doesn't explain it at all. In fact I don't see why we neeed > > three attempts, just do the GFP_NOFAIL as the second and final step. > > Second attempt is reduced size only as we don't want to GFP_NOFAIL > if we can avoid it helping the allocator. We go from an arbitrary > allocation to the smallest possible allocation, if all that fails > ok lets use GFP_NOFAIL. I don't know how this is not clear... That's exactly what you need to explain in the patch or the commit message. In fact you still haven't explained it fully. Why do we need a second attempt without the GFP_NOFAIL? How does it help the allocator? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt