Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3672147imm; Tue, 29 May 2018 11:18:15 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqFjcy7Q7MSUcbFEu9UXPeai7g3zWHVzFWLI0HRh2V6kxr/Inshg1i4mH3VF+WmMna2gGjr X-Received: by 2002:a17:902:6903:: with SMTP id j3-v6mr18759106plk.313.1527617895068; Tue, 29 May 2018 11:18:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527617895; cv=none; d=google.com; s=arc-20160816; b=uisevF0XXMLNbVZsys05ytj3hL285SgRVen02TQCgh02BDT1TsrMqWKZLf74RgS1KX 82jxquEV9OeMR7OtDHJ2ZcRKPzpA9J/QjlqS4tjlavZKpYWvwPpm40krPssUGFvwcPiv enYKg/lVFAw8bx7icGWHKzZvUEIq7dpZkTd2XvN2IwkkKdlplc5O8lQC/XxNfi3v8WYS welmCmYeV+3MvPHJKPOczr24wNYwRp+oeWunn+QMcO/7yOUu6IAlHqDN+PJXu8Bgx5It lkligihzZVFWsTTLMeiP80kVR79FUTS9ZF/vEf9kmEPR9zQ1F4glklU1TNTyaC/7XHhs GdBA== 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=vcXEerBTLCSNl+2Z7DZa138VgDQsG1e8vrNy8pDxrOM=; b=E6fA8tA3ANTJn6lmgYM6LmLR8p7w3CnC26uiO6eiZqxJRgfaUvFmuKVoeyxIhfbPco dzDEU2mZailtivHHTqEs7mXXgu3Q3VOGJ8nCXc2z3MgjnqXKxR4eqcaxHpanF9jNyhop HbYvvJdC37DolJtErw8IV2+gLBg2M92DtRT+/uPYab2UlFyPVGYut9V2yEdVeoVfkt23 5Zonr5qB5aQEktS3uUc5AOrTcimOCncgm8GfvxGQvLI1Y2edeGQtDDMzFNEoSZ5whJLt vkRAOmx2zRlfFolL7j40ITndVKODfMEvfW7Gwb/JV1arlxfu2YlDf03aBfj+aWtaV+MS UhRw== 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 o11-v6si2355902pgq.506.2018.05.29.11.18.00; Tue, 29 May 2018 11:18:15 -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 S965871AbeE2SQS (ORCPT + 99 others); Tue, 29 May 2018 14:16:18 -0400 Received: from mx2.suse.de ([195.135.220.15]:48011 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965718AbeE2SQQ (ORCPT ); Tue, 29 May 2018 14:16:16 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 0DECBAE04; Tue, 29 May 2018 18:16:15 +0000 (UTC) Date: Tue, 29 May 2018 10:59:27 -0700 From: Davidlohr Bueso To: Herbert Xu 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: <20180529175927.iyea653hpgnow6p2@linux-n805> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20180529180428.l6yt6ae4oxbgrja6@gondor.apana.org.au> User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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... Thanks, Davidlohr