From: Uladzislau Rezki <urezki@gmail.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Uladzislau Rezki <urezki@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Vlastimil Babka <vbabka@suse.cz>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Nicholas Piggin <npiggin@gmail.com>
Subject: Re: [PATCH 2/2] mm/vmalloc: Use kvmalloc to allocate the table of pages
Date: Tue, 23 Mar 2021 13:04:36 +0100 [thread overview]
Message-ID: <20210323120436.GA1949@pc638.lan> (raw)
In-Reply-To: <20210322230311.GY1719932@casper.infradead.org>
On Mon, Mar 22, 2021 at 11:03:11PM +0000, Matthew Wilcox wrote:
> On Mon, Mar 22, 2021 at 11:36:19PM +0100, Uladzislau Rezki wrote:
> > On Mon, Mar 22, 2021 at 07:38:20PM +0000, Matthew Wilcox (Oracle) wrote:
> > > If we're trying to allocate 4MB of memory, the table will be 8KiB in size
> > > (1024 pointers * 8 bytes per pointer), which can usually be satisfied
> > > by a kmalloc (which is significantly faster). Instead of changing this
> > > open-coded implementation, just use kvmalloc().
> > >
> > > Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> > > ---
> > > mm/vmalloc.c | 7 +------
> > > 1 file changed, 1 insertion(+), 6 deletions(-)
> > >
> > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > > index 96444d64129a..32b640a84250 100644
> > > --- a/mm/vmalloc.c
> > > +++ b/mm/vmalloc.c
> > > @@ -2802,13 +2802,8 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> > > gfp_mask |= __GFP_HIGHMEM;
> > >
> > > /* Please note that the recursion is strictly bounded. */
> > > - if (array_size > PAGE_SIZE) {
> > > - pages = __vmalloc_node(array_size, 1, nested_gfp, node,
> > > + pages = kvmalloc_node_caller(array_size, nested_gfp, node,
> > > area->caller);
> > > - } else {
> > > - pages = kmalloc_node(array_size, nested_gfp, node);
> > > - }
> > > -
> > > if (!pages) {
> > > free_vm_area(area);
> > > return NULL;
> > > --
> > > 2.30.2
> > Makes sense to me. Though i expected a bigger difference:
> >
> > # patch
> > single CPU, 4MB allocation, loops: 1000000 avg: 85293854 usec
> >
> > # default
> > single CPU, 4MB allocation, loops: 1000000 avg: 89275857 usec
>
> Well, 4.5% isn't something to leave on the table ... but yeah, I was
> expecting more in the 10-20% range. It may be more significant if
> there's contention on the spinlocks (like if this crazy ksmbd is calling
> vmalloc(4MB) on multiple nodes simultaneously).
>
Yep, it can be that simultaneous allocations will show even bigger
improvements because of lock contention. Anyway there is an advantage
in switching to SLAB - 5% is also a win :)
>
> I suspect the vast majority of the time is spent calling alloc_pages_node()
> 1024 times. Have you looked at Mel's patch to do ... well, exactly what
> vmalloc() wants?
>
<snip>
- 97.37% 0.00% vmalloc_test/0 [kernel.vmlinux] [k] ret_from_fork ◆
ret_from_fork ▒
kthread ▒
- 0xffffffffc047373b ▒
- 52.67% 0xffffffffc047349f ▒
__vmalloc_node ▒
- __vmalloc_node_range ▒
- 45.25% __alloc_pages_nodemask ▒
- 37.59% get_page_from_freelist ▒
4.34% __list_del_entry_valid ▒
3.67% __list_add_valid ▒
1.52% prep_new_page ▒
1.20% check_preemption_disabled ▒
3.75% map_kernel_range_noflush ▒
- 0.64% kvmalloc_node_caller ▒
__kmalloc_track_caller ▒
memset_orig ▒
- 44.61% 0xffffffffc047348d ▒
- __vunmap ▒
- 35.56% free_unref_page ▒
- 22.48% free_pcppages_bulk ▒
- 4.21% __mod_zone_page_state ▒
2.78% check_preemption_disabled ▒
0.80% __this_cpu_preempt_check ▒
2.24% __list_del_entry_valid ▒
1.84% __list_add_valid ▒
- 6.55% free_unref_page_commit ▒
2.47% check_preemption_disabled ▒
1.36% __list_add_valid ▒
3.10% free_unref_page_prepare.part.88 ▒
0.72% free_pcp_prepare ▒
- 6.26% remove_vm_area ▒
6.18% unmap_kernel_range_noflush ▒
2.31% __free_pages
<snip>
__alloc_pages_nodemask() consumes lot of cycles because it is called
one time per a page and like you mentioned, for 4MB request it is invoked
1024 times!
>
> https://lore.kernel.org/linux-mm/20210322091845.16437-1-mgorman@techsingularity.net/
>
I saw it. It would be good to switch to the bulk interface for vmalloc
once it is settled and mainlined. Apart of that, i find it also useful
for the kvfree_rcu() code in a context of page-cache refilling :)
>
> > One question. Should we care much about fragmentation? I mean
> > with the patch, allocations > 2MB will do request to SLAB bigger
> > then PAGE_SIZE.
>
> We're pretty good about allocating memory in larger chunks these days.
> Looking at my laptop's slabinfo,
> kmalloc-8k 219 232 8192 4 8 : tunables 0 0 0 : sla
> bdata 58 58 0
>
> That's using 8 pages per slab, so that's order-3 allocations. There's a
> few more of those:
>
> $ sudo grep '8 :' /proc/slabinfo |wc
> 42 672 4508
>
> so I have confidence that kvmalloc() will manage to use kmalloc up to 16MB
> vmalloc allocations, and after that it'll tend to fall back to vmalloc.
>
Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
Thanks!
--
Vlad Rezki
next prev parent reply other threads:[~2021-03-23 12:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-22 19:38 [PATCH 1/2] mm/util: Add kvmalloc_node_caller Matthew Wilcox (Oracle)
2021-03-22 19:38 ` [PATCH 2/2] mm/vmalloc: Use kvmalloc to allocate the table of pages Matthew Wilcox (Oracle)
2021-03-22 22:36 ` Uladzislau Rezki
2021-03-22 23:03 ` Matthew Wilcox
2021-03-23 12:04 ` Uladzislau Rezki [this message]
2021-03-23 12:39 ` Matthew Wilcox
2021-03-23 13:39 ` Uladzislau Rezki
2021-03-23 14:07 ` Matthew Wilcox
2021-03-23 20:49 ` Uladzislau Rezki
2021-03-23 20:39 ` Uladzislau Rezki
2021-03-24 18:41 ` Uladzislau Rezki
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=20210323120436.GA1949@pc638.lan \
--to=urezki@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@gmail.com \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--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.