From: Song Liu <song@kernel.org>
To: Mike Rapoport <rppt@kernel.org>
Cc: Kent Overstreet <kent.overstreet@linux.dev>,
linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Rick Edgecombe <rick.p.edgecombe@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Vlastimil Babka <vbabka@suse.cz>,
linux-kernel@vger.kernel.org, x86@kernel.org
Subject: Re: [RFC PATCH 1/5] mm: intorduce __GFP_UNMAPPED and unmapped_alloc()
Date: Fri, 19 May 2023 08:42:38 -0700 [thread overview]
Message-ID: <CAPhsuW6xsHupB2EGGrgEdd+13ORSvPAymRgnrAfxG2U0Jfo4vQ@mail.gmail.com> (raw)
In-Reply-To: <20230519082945.GE4967@kernel.org>
On Fri, May 19, 2023 at 1:30 AM Mike Rapoport <rppt@kernel.org> wrote:
>
> Hi Kent,
>
> On Thu, May 18, 2023 at 01:23:56PM -0400, Kent Overstreet wrote:
> > On Thu, May 18, 2023 at 10:00:39AM -0700, Song Liu wrote:
> > > On Thu, May 18, 2023 at 9:48 AM Kent Overstreet
> > > <kent.overstreet@linux.dev> wrote:
> > > >
> > > > On Thu, May 18, 2023 at 09:33:20AM -0700, Song Liu wrote:
> > > > > I am working on patches based on the discussion in [1]. I am planning to
> > > > > send v1 for review in a week or so.
> > > >
> > > > Hey Song, I was reviewing that thread too,
> > > >
> > > > Are you taking a different approach based on Thomas's feedback? I think
> > > > he had some fair points in that thread.
> > >
> > > Yes, the API is based on Thomas's suggestion, like 90% from the discussions.
> > >
> > > >
> > > > My own feeling is that the buddy allocator is our tool for allocating
> > > > larger variable sized physically contiguous allocations, so I'd like to
> > > > see something based on that - I think we could do a hybrid buddy/slab
> > > > allocator approach, like we have for regular memory allocations.
> > >
> > > I am planning to implement the allocator based on this (reuse
> > > vmap_area logic):
> >
> > Ah, you're still doing vmap_area approach.
> >
> > Mike's approach looks like it'll be _much_ lighter weight and higher
> > performance, to me. vmalloc is known to be slow compared to the buddy
> > allocator, and with Mike's approach we're only modifying mappings once
> > per 2 MB chunk.
> >
> > I don't see anything in your code for sub-page sized allocations too, so
> > perhaps I should keep going with my slab allocator.
>
> Your allocator implicitly relies on vmalloc because of module_alloc ;-)
>
> What I was thinking is that we can replace module_alloc() calls in your
> allocator with something based on my unmapped_alloc(). If we make the part
> that refills the cache also take care of creating the mapping in the
> module address space, that should cover everything.
Here are what I found as I work more on the code:
1. It takes quite some work to create a clean interface and make sure
all the users of module_alloc can use the new allocator on all archs.
(archs with text poke need to work with ROX memory from the
allocator; archs without text poke need to have a clean fall back
mechanism, etc.). Most of this work is independent of the actual
allocator, so we can do this part and plug in whatever allocator we
want (buddy+slab or vmap-based or any other solutions).
2. vmap_area based solution will work. And it will be one solution for
both < PAGE_SIZE and > PAGE_SIZE allocations. Given
module_alloc is not in any hot path (AFAIK), I don't see any
practical issues with this solution. It will be a little tricky to place
and name the code, as it uses vmalloc logic, but it is technically a
module allocator.
I will prioritize building the interface, and migrating users to it. If we
do this part right, changing the underlying allocator should be
straightforward.
Thanks,
Song
next prev parent reply other threads:[~2023-05-19 15:42 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-08 9:41 [RFC PATCH 0/5] Prototype for direct map awareness in page allocator Mike Rapoport
2023-03-08 9:41 ` [RFC PATCH 1/5] mm: intorduce __GFP_UNMAPPED and unmapped_alloc() Mike Rapoport
2023-03-09 1:56 ` Edgecombe, Rick P
2023-03-09 14:39 ` Mike Rapoport
2023-03-09 15:34 ` Edgecombe, Rick P
2023-03-09 6:31 ` Hyeonggon Yoo
2023-03-09 15:27 ` Mike Rapoport
2023-03-24 8:37 ` Michal Hocko
2023-03-25 6:38 ` Mike Rapoport
2023-03-27 13:43 ` Michal Hocko
2023-03-27 14:31 ` Vlastimil Babka
2023-03-27 15:10 ` Michal Hocko
2023-03-28 6:25 ` Mike Rapoport
2023-03-28 7:39 ` Michal Hocko
2023-03-28 15:11 ` Mike Rapoport
2023-03-28 15:24 ` Michal Hocko
2023-03-29 7:28 ` Mike Rapoport
2023-03-29 8:13 ` Michal Hocko
2023-03-30 5:13 ` Mike Rapoport
2023-03-30 8:11 ` Michal Hocko
2023-03-28 17:18 ` Luis Chamberlain
2023-03-28 17:37 ` Matthew Wilcox
2023-03-28 17:52 ` Luis Chamberlain
2023-03-28 17:55 ` Luis Chamberlain
2023-05-18 3:35 ` Kent Overstreet
2023-05-18 15:23 ` Mike Rapoport
2023-05-18 16:33 ` Song Liu
2023-05-18 16:48 ` Kent Overstreet
2023-05-18 17:00 ` Song Liu
2023-05-18 17:23 ` Kent Overstreet
2023-05-18 18:47 ` Song Liu
2023-05-18 19:03 ` Song Liu
2023-05-18 19:15 ` Kent Overstreet
2023-05-18 20:03 ` Song Liu
2023-05-18 20:13 ` Kent Overstreet
2023-05-18 20:51 ` Song Liu
2023-05-19 1:24 ` Kent Overstreet
2023-05-19 15:08 ` Song Liu
2023-05-18 19:16 ` Kent Overstreet
2023-05-19 8:29 ` Mike Rapoport
2023-05-19 15:42 ` Song Liu [this message]
2023-05-22 22:05 ` Thomas Gleixner
2023-05-19 15:47 ` Kent Overstreet
2023-05-19 16:14 ` Mike Rapoport
2023-05-19 16:21 ` Kent Overstreet
2023-05-18 16:58 ` Kent Overstreet
2023-05-18 17:15 ` Song Liu
2023-05-18 17:25 ` Kent Overstreet
2023-05-18 18:54 ` Song Liu
2023-05-18 19:01 ` Song Liu
2023-05-18 19:10 ` Kent Overstreet
2023-03-08 9:41 ` [RFC PATCH 2/5] mm/unmapped_alloc: add debugfs file similar to /proc/pagetypeinfo Mike Rapoport
2023-03-08 9:41 ` [RFC PATCH 3/5] mm/unmapped_alloc: add shrinker Mike Rapoport
2023-03-08 9:41 ` [RFC PATCH 4/5] EXPERIMENTAL: x86: use __GFP_UNMAPPED for modele_alloc() Mike Rapoport
2023-03-09 1:54 ` Edgecombe, Rick P
2023-03-08 9:41 ` [RFC PATCH 5/5] EXPERIMENTAL: mm/secretmem: use __GFP_UNMAPPED Mike Rapoport
2023-03-09 1:59 ` [RFC PATCH 0/5] Prototype for direct map awareness in page allocator Edgecombe, Rick P
2023-03-09 15:14 ` Mike Rapoport
2023-05-19 15:40 ` Sean Christopherson
2023-05-19 16:24 ` Mike Rapoport
2023-05-19 18:25 ` Sean Christopherson
2023-05-25 20:37 ` Mike Rapoport
2023-03-10 7:27 ` Christoph Hellwig
2023-03-27 14:27 ` Mike Rapoport
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=CAPhsuW6xsHupB2EGGrgEdd+13ORSvPAymRgnrAfxG2U0Jfo4vQ@mail.gmail.com \
--to=song@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@linux.intel.com \
--cc=kent.overstreet@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=rppt@kernel.org \
--cc=tglx@linutronix.de \
--cc=vbabka@suse.cz \
--cc=x86@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 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.