From: Xunlei Pang <xlpang@linux.alibaba.com>
To: Christoph Lameter <cl@linux.com>,
Christoph Lameter <cl@gentwo.de>,
Pekka Enberg <penberg@kernel.org>,
Vlastimil Babka <vbabka@suse.cz>, Roman Gushchin <guro@fb.com>,
Konstantin Khlebnikov <khlebnikov@yandex-team.ru>,
David Rientjes <rientjes@google.com>,
Matthew Wilcox <willy@infradead.org>,
Shu Ming <sming56@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Wen Yang <wenyang@linux.alibaba.com>,
James Wang <jnwang@linux.alibaba.com>,
Xunlei Pang <xlpang@linux.alibaba.com>
Subject: [PATCH v4 0/3] mm/slub: Fix count_partial() problem
Date: Wed, 17 Mar 2021 15:54:49 +0800 [thread overview]
Message-ID: <1615967692-80524-1-git-send-email-xlpang@linux.alibaba.com> (raw)
count_partial() can hold n->list_lock spinlock for quite long, which
makes much trouble to the system. This series eliminate this problem.
v1->v2:
- Improved changelog and variable naming for PATCH 1~2.
- PATCH3 adds per-cpu counter to avoid performance regression
in concurrent __slab_free().
v2->v3:
- Changed "page->inuse" to the safe "new.inuse", etc.
- Used CONFIG_SLUB_DEBUG and CONFIG_SYSFS condition for new counters.
- atomic_long_t -> unsigned long
v3->v4:
- introduced new CONFIG_SLUB_DEBUG_PARTIAL to give a chance to be enabled for production use.
- Merged PATCH 4 into PATCH 1.
[Testing]
There seems might be a little performance impact under extreme
__slab_free() concurrent calls according to my tests.
On my 32-cpu 2-socket physical machine:
Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz
1) perf stat --null --repeat 10 -- hackbench 20 thread 20000
== original, no patched
Performance counter stats for 'hackbench 20 thread 20000' (10 runs):
24.536050899 seconds time elapsed ( +- 0.24% )
Performance counter stats for 'hackbench 20 thread 20000' (10 runs):
24.588049142 seconds time elapsed ( +- 0.35% )
== patched with patch1~4
Performance counter stats for 'hackbench 20 thread 20000' (10 runs):
24.670892273 seconds time elapsed ( +- 0.29% )
Performance counter stats for 'hackbench 20 thread 20000' (10 runs):
24.746755689 seconds time elapsed ( +- 0.21% )
2) perf stat --null --repeat 10 -- hackbench 32 thread 20000
== original, no patched
Performance counter stats for 'hackbench 32 thread 20000' (10 runs):
39.784911855 seconds time elapsed ( +- 0.14% )
Performance counter stats for 'hackbench 32 thread 20000' (10 runs):
39.868687608 seconds time elapsed ( +- 0.19% )
== patched with patch1~4
Performance counter stats for 'hackbench 32 thread 20000' (10 runs):
39.681273015 seconds time elapsed ( +- 0.21% )
Performance counter stats for 'hackbench 32 thread 20000' (10 runs):
39.681238459 seconds time elapsed ( +- 0.09% )
Xunlei Pang (3):
mm/slub: Introduce two counters for partial objects
percpu: Export per_cpu_sum()
mm/slub: Get rid of count_partial()
include/linux/percpu-defs.h | 10 ++++
init/Kconfig | 13 +++++
kernel/locking/percpu-rwsem.c | 10 ----
mm/slab.h | 6 ++
mm/slub.c | 129 +++++++++++++++++++++++++++++-------------
5 files changed, 120 insertions(+), 48 deletions(-)
--
1.8.3.1
next reply other threads:[~2021-03-17 7:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-17 7:54 Xunlei Pang [this message]
2021-03-17 7:54 ` [PATCH v4 1/3] mm/slub: Introduce two counters for partial objects Xunlei Pang
2021-03-17 18:45 ` Vlastimil Babka
2021-03-18 4:52 ` Xunlei Pang
2021-03-18 12:18 ` Vlastimil Babka
2021-03-18 12:56 ` Xunlei Pang
2021-03-22 1:46 ` Shu Ming
2021-03-22 10:22 ` Vlastimil Babka
2021-03-29 1:58 ` Shu Ming
2021-03-17 7:54 ` [PATCH v4 2/3] percpu: Export per_cpu_sum() Xunlei Pang
2021-03-17 7:54 ` [PATCH v4 3/3] mm/slub: Get rid of count_partial() Xunlei Pang
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=1615967692-80524-1-git-send-email-xlpang@linux.alibaba.com \
--to=xlpang@linux.alibaba.com \
--cc=akpm@linux-foundation.org \
--cc=cl@gentwo.de \
--cc=cl@linux.com \
--cc=guro@fb.com \
--cc=jnwang@linux.alibaba.com \
--cc=khlebnikov@yandex-team.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=sming56@gmail.com \
--cc=vbabka@suse.cz \
--cc=wenyang@linux.alibaba.com \
--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 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).