From: Michal Hocko <mhocko@kernel.org>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Hugh Dickins <hughd@google.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Andi Kleen <ak@linux.intel.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] shmem: avoid huge pages for small files
Date: Tue, 18 Oct 2016 16:20:07 +0200 [thread overview]
Message-ID: <20161018142007.GL12092@dhcp22.suse.cz> (raw)
In-Reply-To: <20161017145539.GA26930@node.shutemov.name>
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.
> 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?
--
Michal Hocko
SUSE Labs
--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Hugh Dickins <hughd@google.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Andi Kleen <ak@linux.intel.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] shmem: avoid huge pages for small files
Date: Tue, 18 Oct 2016 16:20:07 +0200 [thread overview]
Message-ID: <20161018142007.GL12092@dhcp22.suse.cz> (raw)
In-Reply-To: <20161017145539.GA26930@node.shutemov.name>
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.
> 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?
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2016-10-18 14:20 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-17 12:18 [PATCH] shmem: avoid huge pages for small files Kirill A. Shutemov
2016-10-17 12:18 ` Kirill A. Shutemov
2016-10-17 12:30 ` Kirill A. Shutemov
2016-10-17 12:30 ` Kirill A. Shutemov
2016-10-17 14:12 ` Michal Hocko
2016-10-17 14:12 ` Michal Hocko
2016-10-17 14:55 ` Kirill A. Shutemov
2016-10-17 14:55 ` Kirill A. Shutemov
2016-10-18 14:20 ` Michal Hocko [this message]
2016-10-18 14:20 ` Michal Hocko
2016-10-18 14:32 ` Kirill A. Shutemov
2016-10-18 14:32 ` Kirill A. Shutemov
2016-10-18 18:30 ` Michal Hocko
2016-10-18 18:30 ` Michal Hocko
2016-10-19 18:13 ` Hugh Dickins
2016-10-19 18:13 ` Hugh Dickins
2016-10-20 10:39 ` Kirill A. Shutemov
2016-10-20 10:39 ` Kirill A. Shutemov
2016-10-20 22:46 ` Dave Chinner
2016-10-20 22:46 ` Dave Chinner
2016-10-21 2:01 ` Andi Kleen
2016-10-21 2:01 ` Andi Kleen
2016-10-21 5:01 ` Dave Chinner
2016-10-21 5:01 ` Dave Chinner
2016-10-21 15:00 ` Kirill A. Shutemov
2016-10-21 15:00 ` Kirill A. Shutemov
2016-10-21 15:12 ` Michal Hocko
2016-10-21 15:12 ` Michal Hocko
2016-10-21 22:50 ` Dave Chinner
2016-10-21 22:50 ` Dave Chinner
2016-10-21 23:32 ` Kirill A. Shutemov
2016-10-21 23:32 ` Kirill A. Shutemov
2016-10-24 20:34 ` Dave Hansen
2016-10-24 20:34 ` Dave Hansen
2016-10-25 5:28 ` Dave Chinner
2016-10-25 5:28 ` Dave Chinner
-- strict thread matches above, loose matches on Subject: below --
2016-11-10 16:25 [PATCHv4] " Kirill A. Shutemov
2016-11-10 17:42 ` [PATCH] " kbuild test robot
2016-11-10 17:51 ` Kirill A. Shutemov
2016-11-10 17:51 ` Kirill A. Shutemov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161018142007.GL12092@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=aarcange@redhat.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.