From: Uladzislau Rezki <urezki@gmail.com>
To: lsf-pc@lists.linux-foundation.org
Cc: linux-mm@kvack.org, urezki@gmail.com
Subject: LSFMMBPF proposal [MM]: Eliminate vmap/vmalloc lock contention
Date: Tue, 28 Feb 2023 17:42:43 +0100 [thread overview]
Message-ID: <Y/4vA1xdagP5UFVI@pc636> (raw)
Hello, LSF.
Title: Introduce a per-cpu-vmap-cache to eliminate a vmap lock contention
Description:
Currently the vmap code is not scaled to number of CPU cores in a system
because a global vmap space is protected by a single spinlock. Such approach
has a clear bottleneck if many CPUs simultaneously access to one resource.
In this talk i would like to describe a drawback, show some data related
to contentions and places where those occur in a code. Apart of that i
would like to share ideas how to eliminate it providing a few approaches
and compare them.
Requirements:
* It should be a per-cpu approach;
* Search of freed ptrs should not interfere with other freeing(as much as we can);
* - offload allocated areas(buzy ones) per-cpu;
* Cache ready sized objects or merge them into one big per-cpu-space(split on demand);
* Lazily-freed areas either drained per-cpu individually or by one CPU for all;
* Prefetch a fixed size in front and allocate per-cpu
Goals:
* Implement a per-cpu way of allocation to eliminate a contention.
Thanks!
--
Uladzislau Rezki
next reply other threads:[~2023-02-28 16:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-28 16:42 Uladzislau Rezki [this message]
2023-03-21 7:48 ` LSFMMBPF proposal [MM]: Eliminate vmap/vmalloc lock contention Lorenzo Stoakes
2023-04-21 12:03 ` [Lsf-pc] " Michal Hocko
2023-04-24 7:44 ` Uladzislau Rezki
2023-04-24 8:55 ` Michal Hocko
2023-04-24 10:08 ` Uladzislau Rezki
2023-04-24 10:22 ` Lorenzo Stoakes
2023-04-25 1:11 ` Baoquan He
2023-05-11 16:46 ` 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=Y/4vA1xdagP5UFVI@pc636 \
--to=urezki@gmail.com \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.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.