From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031350AbdAIOcd (ORCPT ); Mon, 9 Jan 2017 09:32:33 -0500 Received: from mail-io0-f175.google.com ([209.85.223.175]:35329 "EHLO mail-io0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030714AbdAIObv (ORCPT ); Mon, 9 Jan 2017 09:31:51 -0500 MIME-Version: 1.0 In-Reply-To: <20170109095828.GE7495@dhcp22.suse.cz> References: <20170106095115.GG5556@dhcp22.suse.cz> <20170106100433.GH5556@dhcp22.suse.cz> <20170106121642.GJ5556@dhcp22.suse.cz> <1483740889.9712.44.camel@edumazet-glaptop3.roam.corp.google.com> <20170107092746.GC5047@dhcp22.suse.cz> <20170109095828.GE7495@dhcp22.suse.cz> From: Eric Dumazet Date: Mon, 9 Jan 2017 06:31:50 -0800 Message-ID: Subject: Re: weird allocation pattern in alloc_ila_locks To: Michal Hocko Cc: Eric Dumazet , Tom Herbert , linux-mm@kvack.org, LKML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 9, 2017 at 1:58 AM, Michal Hocko wrote: > > Also this seems to be an init code so I assume a modprobe would have to > set a non-default policy to make use of it. Does anybody do that out > there? This is not init code. Whole point of rhashtable is that the resizes can happen anytime. At boot time, most rhashtable would be tiny. Then, when load permits, hashtables grow in size. Yes, some applications make some specific choices about NUMA policies. It would be perfectly possible to amend rhashtable to make sure that allocations can respect this strategy. (ie the NUMA policy could be an attribute of the rhashtable, instead of being implicitly given by current process)