From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934130AbcJROc1 (ORCPT ); Tue, 18 Oct 2016 10:32:27 -0400 Received: from mail-lf0-f67.google.com ([209.85.215.67]:34738 "EHLO mail-lf0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932597AbcJROcL (ORCPT ); Tue, 18 Oct 2016 10:32:11 -0400 Date: Tue, 18 Oct 2016 17:32:07 +0300 From: "Kirill A. Shutemov" To: Michal Hocko Cc: "Kirill A. Shutemov" , Hugh Dickins , Andrea Arcangeli , Andrew Morton , Andi Kleen , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] shmem: avoid huge pages for small files Message-ID: <20161018143207.GA5833@node.shutemov.name> References: <20161017121809.189039-1-kirill.shutemov@linux.intel.com> <20161017123021.rlyz44dsf4l4xnve@black.fi.intel.com> <20161017141245.GC27459@dhcp22.suse.cz> <20161017145539.GA26930@node.shutemov.name> <20161018142007.GL12092@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161018142007.GL12092@dhcp22.suse.cz> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 18, 2016 at 04:20:07PM +0200, Michal Hocko wrote: > On Mon 17-10-16 17:55:40, Kirill A. Shutemov wrote: > > On Mon, Oct 17, 2016 at 04:12:46PM +0200, Michal Hocko wrote: > > > On Mon 17-10-16 15:30:21, Kirill A. Shutemov wrote: > [...] > > > > We add two handle to specify minimal file size for huge pages: > > > > > > > > - mount option 'huge_min_size'; > > > > > > > > - sysfs file /sys/kernel/mm/transparent_hugepage/shmem_min_size for > > > > in-kernel tmpfs mountpoint; > > > > > > Could you explain who might like to change the minimum value (other than > > > disable the feautre for the mount point) and for what reason? > > > > Depending on how well CPU microarchitecture deals with huge pages, you > > might need to set it higher in order to balance out overhead with benefit > > of huge pages. > > I am not sure this is a good argument. How do a user know and what will > help to make that decision? Why we cannot autotune that? In other words, > adding new knobs just in case turned out to be a bad idea in the past. Well, I don't see a reasonable way to autotune it. We can just let arch-specific code to redefine it, but the argument below still stands. > > In other case, if it's known in advance that specific mount would be > > populated with large files, you might want to set it to zero to get huge > > pages allocated from the beginning. > > Cannot we use [mf]advise for that purpose? There's no fadvise for this at the moment. We can use madvise, except that the patch makes it lower priority than the limit :P. I'll fix that. But in general, it would require change to the program which is not always desirable or even possible. -- Kirill A. Shutemov