From: Mike Rapoport <rppt@kernel.org>
To: Michal Hocko <mhocko@suse.com>
Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org,
Dan Williams <dan.j.williams@intel.com>
Subject: Re: [Lsf-pc] [LSF/MM/BPF TOPIC] reducing direct map fragmentation
Date: Fri, 21 Apr 2023 12:47:06 +0300 [thread overview]
Message-ID: <ZEJbmjEyuciT7af6@kernel.org> (raw)
In-Reply-To: <ZEJR0GPSG4pbAQcD@dhcp22.suse.cz>
On Fri, Apr 21, 2023 at 11:05:20AM +0200, Michal Hocko wrote:
> Hi,
>
> On Wed 01-02-23 20:06:37, Mike Rapoport wrote:
> [...]
> > My current proposal is to have a cache of 2M pages close to the page
> > allocator and use a GFP flag to make allocation request use that cache. On
> > the free() path, the pages that are mapped at PTE level will be put into
> > that cache.
>
> Are there stil open questions which would benefit from a discussion at
> LSFMM this year?
Yes, I believe.
I was trying to get some numbers to see what would be the benefit of
__GFP_UNMAPPED and I couldn't find a benchmark that will produce results
with good signal-to-noise ratio.
So while it seems that there's a general agreement on how to implement
caching of 2M pages, there is still no evidence that it will be universally
useful.
It would be interesting to discuss the reasons for inconclusive results,
and more importantly, what should be the general direction for dealing with
the direct map fragmentation.
As it seems now, packing code allocations into 2M pages would be an
improvement, while data allocations that fragment the direct map do not
impact much the overall system performance.
I'll bring the mmtest results I have to begin the discussion.
> --
> Michal Hocko
> SUSE Labs
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2023-04-21 9:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-01 18:06 [LSF/MM/BPF TOPIC] reducing direct map fragmentation Mike Rapoport
2023-02-19 8:07 ` Hyeonggon Yoo
2023-02-19 18:09 ` Mike Rapoport
2023-02-20 14:43 ` Hyeonggon Yoo
2023-02-24 14:45 ` Mike Rapoport
2023-04-21 9:05 ` [Lsf-pc] " Michal Hocko
2023-04-21 9:47 ` Mike Rapoport [this message]
2023-04-21 12:41 ` Michal Hocko
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=ZEJbmjEyuciT7af6@kernel.org \
--to=rppt@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=mhocko@suse.com \
/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;
as well as URLs for NNTP newsgroup(s).