From: Roman Gushchin <guro@fb.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Roman Gushchin <guroan@gmail.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Matthew Wilcox <willy@infradead.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Kernel Team <Kernel-team@fb.com>
Subject: Re: [PATCH 2/3] mm: separate memory allocation and actual work in alloc_vmap_area()
Date: Wed, 17 Apr 2019 19:15:41 +0000 [thread overview]
Message-ID: <20190417191535.GA16663@tower.DHCP.thefacebook.com> (raw)
In-Reply-To: <ed835e2c-9357-c7ea-f458-0cd9b8f6e966@suse.cz>
On Wed, Apr 17, 2019 at 03:27:56PM +0200, Vlastimil Babka wrote:
> On 3/1/19 5:48 PM, Roman Gushchin wrote:
> > On Fri, Mar 01, 2019 at 03:43:19PM +0100, Vlastimil Babka wrote:
> >> On 2/25/19 9:30 PM, Roman Gushchin wrote:
> >>> alloc_vmap_area() is allocating memory for the vmap_area, and
> >>> performing the actual lookup of the vm area and vmap_area
> >>> initialization.
> >>>
> >>> This prevents us from using a pre-allocated memory for the map_area
> >>> structure, which can be used in some cases to minimize the number
> >>> of required memory allocations.
> >>
> >> Hmm, but that doesn't happen here or in the later patch, right? The only
> >> caller of init_vmap_area() is alloc_vmap_area(). What am I missing?
> >
> > So initially the patch was a part of a bigger patchset, which
> > tried to minimize the number of separate allocations during vmalloc(),
> > e.g. by inlining vm_struct->pages into vm_struct for small areas.
> >
> > I temporarily dropped the rest of the patchset for some rework,
> > but decided to leave this patch, because it looks like a nice refactoring
> > in any case, and also it has been already reviewed and acked by Matthew
> > and Johannes.
>
> OK then,
>
> Acked-by: Vlastimil Babka <vbabka@suse.cz>
Thank you for looking into this and other patches from the series!
Btw, it looks like that recent changes in vmalloc code are in a conflict
with this patch, so I'll drop it for now, and will resend two other as v4.
Thanks!
next prev parent reply other threads:[~2019-04-17 19:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-25 20:30 [PATCH 0/3] vmalloc enhancements Roman Gushchin
2019-02-25 20:30 ` [PATCH 1/3] mm: refactor __vunmap() to avoid duplicated call to find_vm_area() Roman Gushchin
2019-02-28 15:00 ` Vlastimil Babka
2019-02-25 20:30 ` [PATCH 2/3] mm: separate memory allocation and actual work in alloc_vmap_area() Roman Gushchin
2019-03-01 14:43 ` Vlastimil Babka
2019-03-01 16:48 ` Roman Gushchin
2019-04-17 13:27 ` Vlastimil Babka
2019-04-17 19:15 ` Roman Gushchin [this message]
2019-02-25 20:30 ` [PATCH 3/3] mm: show number of vmalloc pages in /proc/meminfo Roman Gushchin
2019-03-01 15:05 ` Vlastimil Babka
2019-04-17 13:34 ` Vlastimil Babka
2019-03-29 22:07 ` [PATCH 0/3] vmalloc enhancements Roman Gushchin
2019-04-17 13:36 ` Vlastimil Babka
-- strict thread matches above, loose matches on Subject: below --
2018-12-19 17:37 Roman Gushchin
2018-12-19 17:37 ` [PATCH 2/3] mm: separate memory allocation and actual work in alloc_vmap_area() Roman Gushchin
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=20190417191535.GA16663@tower.DHCP.thefacebook.com \
--to=guro@fb.com \
--cc=Kernel-team@fb.com \
--cc=guroan@gmail.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=vbabka@suse.cz \
--cc=willy@infradead.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.