From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756582AbdEUM6y (ORCPT ); Sun, 21 May 2017 08:58:54 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:22974 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753411AbdEUM6t (ORCPT ); Sun, 21 May 2017 08:58:49 -0400 Subject: Re: [v4 1/1] mm: Adaptive hash table scaling To: Andi Kleen Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mhocko@kernel.org References: <1495300013-653283-1-git-send-email-pasha.tatashin@oracle.com> <1495300013-653283-2-git-send-email-pasha.tatashin@oracle.com> <87h90faroe.fsf@firstfloor.org> From: Pasha Tatashin Message-ID: Date: Sun, 21 May 2017 08:58:25 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <87h90faroe.fsf@firstfloor.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Andi, Thank you for looking at this. I mentioned earlier, I would not want to impose a cap. However, if you think that for example dcache needs a cap, there is already a mechanism for that via high_limit argument, so the client can be changed to provide that cap. However, this particular patch addresses scaling problem for everyone by making it scale with memory at a slower pace. Thank you, Pasha On 05/20/2017 10:07 PM, Andi Kleen wrote: > Pavel Tatashin writes: > >> Allow hash tables to scale with memory but at slower pace, when HASH_ADAPT >> is provided every time memory quadruples the sizes of hash tables will only >> double instead of quadrupling as well. This algorithm starts working only >> when memory size reaches a certain point, currently set to 64G. >> >> This is example of dentry hash table size, before and after four various >> memory configurations: > > IMHO the scale is still too aggressive. I find it very unlikely > that a 1TB machine really needs 256MB of hash table because > number of used files are unlikely to directly scale with memory. > > Perhaps should just cap it at some large size, e.g. 32M > > -Andi > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org >