Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp1174747imm; Fri, 22 Jun 2018 11:36:06 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIqOLuwLgOM5v0FZ4HorEay5mFhpMKRvMXxStb2Qs1DqrBBE3JuMMzgcluAa2n2Z6Pnu2z1 X-Received: by 2002:a62:98c9:: with SMTP id d70-v6mr2921153pfk.195.1529692566664; Fri, 22 Jun 2018 11:36:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529692566; cv=none; d=google.com; s=arc-20160816; b=aKRhkswQGBKHz5RhSUlm1ZliEp00jfWozMzfQZWzkZ0FkOOxiYRti83gR9Qf4UuOJg 23Mm+tTEP1qkJs1zD7vrzpfQU4+rcQK4Wyr4RBkO7y7Z/L2hh7CM6R5g8ovK0ZLO4XeB wv9VzfXo3ohn1UnG3pFvAIowbiaMv0vsIf3u1t2o/lyaC5Frv8aTYflf8ffvzfOFiSRz UuHAHlLZ1k/krlRvJlrebEOZ8YbqKYCEXQHh0wyG1ClI91D1xXxBywUkVbbdZCBtcIf1 O8dvQE/sNF9u0vWKCAS82wdZAUtyM6ZQrfqz4B5dxRyvSkL62t1UwoTZLkMIzfpyRoDC sWXQ== 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=kDjmEFhxVtUlM1tUNyGv04A9zPXOGxzSJTLmHQZiwx4=; b=BDg+L4BqwJ4RZBcF5Ia+zW2550N61OpdZAI3y1cfv/9NkflPdonzTuvFmo/akiVWXl kUJ9HdwE4YFPQHBkeLe2bpnfr3GJhpI5Ub9HYaUVB077YHp1XMz86QPHx7/QVGwGY3iQ 9O2Ez8+M+CO+RA4hthMBHSJNaskLreuKkayH0P5ZHe890YydOsQ7NKxNN/e+2pCs2CBv o1ZFoSAM54pqqbFRDBCck3QFvBYwrFmL2QB8UaplcCq+BQvUOQAMaC4nbEdM8BeVXp/6 71WFx9O1kQw8iNegyL1rVmdgR426sJZNW9WCxNYZOhvPN4RFdwC2DH932GKLkBuHkTDy waVg== 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 r7-v6si6534852pgq.675.2018.06.22.11.35.52; Fri, 22 Jun 2018 11:36:06 -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 S934123AbeFVSfK (ORCPT + 99 others); Fri, 22 Jun 2018 14:35:10 -0400 Received: from mx2.suse.de ([195.135.220.15]:54205 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933820AbeFVSfI (ORCPT ); Fri, 22 Jun 2018 14:35:08 -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 CE385AB9F; Fri, 22 Jun 2018 18:35:06 +0000 (UTC) Date: Fri, 22 Jun 2018 11:35:02 -0700 From: Davidlohr Bueso To: akpm@linux-foundation.org, torvalds@linux-foundation.org Cc: tgraf@suug.ch, herbert@gondor.apana.org.au, manfred@colorfullife.com, mhocko@kernel.org, guillaume.knispel@supersonicimagine.com, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, Davidlohr Bueso , neilb@suse.com Subject: Re: [PATCH v2 1/4] lib/rhashtable: simplify bucket_table_alloc() Message-ID: <20180622183502.i5dv4d3tbwh5sw6u@linux-r8p5> References: <20180621212825.3059-1-dave@stgolabs.net> <20180621212825.3059-2-dave@stgolabs.net> <20180622181540.5gul4lx5dteqzzk3@linux-r8p5> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20180622181540.5gul4lx5dteqzzk3@linux-r8p5> User-Agent: NeoMutt/20170912 (1.9.0) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 22 Jun 2018, Davidlohr Bueso wrote: >This slightly changes the gfp flags passed on to nested_table_alloc() as it will now >also use GFP_ATOMIC | __GFP_NOWARN. However, I consider this a positive consequence >as for the same reasons we want nowarn semantics in bucket_table_alloc(). If this is not acceptable, we can just keep the caller's current semantics - the atomic flag could also be labeled 'rehash' or something considering that it comes only from insert_rehash() when we get EAGAIN after trying to insert the first time: diff --git a/lib/rhashtable.c b/lib/rhashtable.c index 9427b5766134..18740b052aec 100644 --- a/lib/rhashtable.c +++ b/lib/rhashtable.c @@ -172,17 +172,15 @@ static struct bucket_table *bucket_table_alloc(struct rhashtable *ht, { struct bucket_table *tbl = NULL; size_t size, max_locks; + bool atomic = (gfp == GFP_ATOMIC); int i; size = sizeof(*tbl) + nbuckets * sizeof(tbl->buckets[0]); - if (gfp != GFP_KERNEL) - tbl = kzalloc(size, gfp | __GFP_NOWARN | __GFP_NORETRY); - else - tbl = kvzalloc(size, gfp); + tbl = kvzalloc(size, atomic ? gfp | __GFP_NOWARN : gfp); size = nbuckets; - if (tbl == NULL && gfp != GFP_KERNEL) { + if (tbl == NULL && atomic) { tbl = nested_bucket_table_alloc(ht, nbuckets, gfp); nbuckets = 0; }