From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756234AbdEUCHe (ORCPT ); Sat, 20 May 2017 22:07:34 -0400 Received: from mga03.intel.com ([134.134.136.65]:25354 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751782AbdEUCHb (ORCPT ); Sat, 20 May 2017 22:07:31 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,372,1491289200"; d="scan'208";a="264484039" From: Andi Kleen To: Pavel Tatashin Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mhocko@kernel.org Subject: Re: [v4 1/1] mm: Adaptive hash table scaling References: <1495300013-653283-1-git-send-email-pasha.tatashin@oracle.com> <1495300013-653283-2-git-send-email-pasha.tatashin@oracle.com> Date: Sat, 20 May 2017 19:07:29 -0700 In-Reply-To: <1495300013-653283-2-git-send-email-pasha.tatashin@oracle.com> (Pavel Tatashin's message of "Sat, 20 May 2017 13:06:53 -0400") Message-ID: <87h90faroe.fsf@firstfloor.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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