From: Hugh Dickins <hughd@google.com>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Hugh Dickins <hughd@google.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Andi Kleen <ak@linux.intel.com>,
Dave Chinner <david@fromorbit.com>,
Michal Hocko <mhocko@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCHv4] shmem: avoid huge pages for small files
Date: Mon, 7 Nov 2016 15:17:11 -0800 (PST) [thread overview]
Message-ID: <alpine.LSU.2.11.1611071433340.1384@eggly.anvils> (raw)
In-Reply-To: <20161021224629.tnwuvruhblkg22qj@black.fi.intel.com>
On Sat, 22 Oct 2016, Kirill A. Shutemov wrote:
>
> Huge pages are detrimental for small file: they causes noticible
> overhead on both allocation performance and memory footprint.
>
> This patch aimed to address this issue by avoiding huge pages until file
> grown to size of huge page. This would cover most of the cases where huge
> pages causes regressions in performance.
>
> Couple notes:
>
> - if shmem_enabled is set to 'force', the limit is ignored. We still
> want to generate as many pages as possible for functional testing.
>
> - the limit doesn't affect khugepaged behaviour: it still can collapse
> pages based on its settings;
>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Sorry, but NAK. I was expecting a patch to tune within_size behaviour.
> ---
> Documentation/vm/transhuge.txt | 3 +++
> mm/shmem.c | 5 +++++
> 2 files changed, 8 insertions(+)
>
> diff --git a/Documentation/vm/transhuge.txt b/Documentation/vm/transhuge.txt
> index 2ec6adb5a4ce..d1889c7c8c46 100644
> --- a/Documentation/vm/transhuge.txt
> +++ b/Documentation/vm/transhuge.txt
> @@ -238,6 +238,9 @@ values:
> - "force":
> Force the huge option on for all - very useful for testing;
>
> +To avoid overhead for small files, we don't allocate huge pages for a file
> +until it grows to size of huge pages.
> +
> == Need of application restart ==
>
> The transparent_hugepage/enabled values and tmpfs mount option only affect
> diff --git a/mm/shmem.c b/mm/shmem.c
> index ad7813d73ea7..49618d2d6330 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -1692,6 +1692,11 @@ static int shmem_getpage_gfp(struct inode *inode, pgoff_t index,
> goto alloc_huge;
> /* TODO: implement fadvise() hints */
> goto alloc_nohuge;
> + case SHMEM_HUGE_ALWAYS:
> + i_size = i_size_read(inode);
> + if (index < HPAGE_PMD_NR && i_size < HPAGE_PMD_SIZE)
> + goto alloc_nohuge;
> + break;
> }
>
> alloc_huge:
So (eliding the SHMEM_HUGE_ADVISE case in between) you now have:
case SHMEM_HUGE_WITHIN_SIZE:
off = round_up(index, HPAGE_PMD_NR);
i_size = round_up(i_size_read(inode), PAGE_SIZE);
if (i_size >= HPAGE_PMD_SIZE &&
i_size >> PAGE_SHIFT >= off)
goto alloc_huge;
goto alloc_nohuge;
case SHMEM_HUGE_ALWAYS:
i_size = i_size_read(inode);
if (index < HPAGE_PMD_NR && i_size < HPAGE_PMD_SIZE)
goto alloc_nohuge;
goto alloc_huge;
I'll concede that those two conditions are not the same; but again you're
messing with huge=always to make it, not always, but conditional on size.
Please, keep huge=always as is: if I copy a 4MiB file into a huge tmpfs,
I got ShmemHugePages 4096 kB before, which is what I wanted. Whereas
with this change I get only 2048 kB, just like with huge=within_size.
Treating the first extent differently is a hack, and does not respect
that this is a filesystem, on which size is likely to increase.
By all means refine the condition for huge=within_size, and by all means
warn in transhuge.txt that huge=always may tend to waste valuable huge
pages if the filesystem is used for small files without good reason
(but maybe the implementation needs to reclaim those more effectively).
Hugh
--
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>
next prev parent reply other threads:[~2016-11-07 23:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-21 18:51 Kirill A. Shutemov
2016-10-21 22:46 ` Kirill A. Shutemov
2016-10-24 12:43 ` Michal Hocko
2016-11-07 23:17 ` Hugh Dickins [this message]
2016-11-10 16:25 ` Kirill A. Shutemov
2016-11-10 17:42 ` [PATCH] " kbuild test robot
2016-11-10 17:51 ` Kirill A. Shutemov
2016-11-11 21:41 ` [PATCHv4] " Hugh Dickins
2016-11-14 14:09 ` Kirill A. Shutemov
2016-11-29 3:56 ` Hugh Dickins
2016-11-29 11:11 ` 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=alpine.LSU.2.11.1611071433340.1384@eggly.anvils \
--to=hughd@google.com \
--cc=aarcange@redhat.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox