From: Jay Patel <jaypatel@linux.ibm.com>
To: Hyeonggon Yoo <42.hyeyoo@gmail.com>,
Vlastimil Babka <vbabka@suse.cz>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
David Rientjes <rientjes@google.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Roman Gushchin <roman.gushchin@linux.dev>,
Feng Tang <feng.tang@intel.com>,
"Sang, Oliver" <oliver.sang@intel.com>,
Binder Makin <merimus@google.com>,
aneesh.kumar@linux.ibm.com, tsahu@linux.ibm.com,
piyushs@linux.ibm.com, fengwei.yin@intel.com,
ying.huang@intel.com, lkp <lkp@intel.com>,
"oe-lkp@lists.linux.dev" <oe-lkp@lists.linux.dev>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC 0/2] An attempt to improve SLUB on NUMA / under memory pressure
Date: Thu, 10 Aug 2023 16:25:49 +0530 [thread overview]
Message-ID: <30b5d85348d84891bf61d7c57370d8b46df8e1a0.camel@linux.ibm.com> (raw)
In-Reply-To: <20230723190906.4082646-1-42.hyeyoo@gmail.com>
On Mon, 2023-07-24 at 04:09 +0900, Hyeonggon Yoo wrote:
> Hello folks,
>
> This series is motivated by kernel test bot report [1] on Jay's patch
> that modifies slab order. While the patch was not merged and not in
> the
> final form, I think it was a good lesson that changing slab order has
> more
> impacts on performance than we expected.
>
> While inspecting the report, I found some potential points to improve
> SLUB. [2] It's _potential_ because it shows no improvements on
> hackbench.
> but I believe more realistic workloads would benefit from this. Due
> to
> lack of resources and lack of my understanding of *realistic*
> workloads,
> I am asking you to help evaluating this together.
Hi Hyeonggon,
I tried hackbench test on Powerpc machine with 16 cpus but
got ~32% of Regression with patch.
Results as
+-------+----+---------+------------+------------+
| | | Normal | With Patch | |
+-------+----+---------+------------+------------+
| Amean | 1 | 1.3700 | 2.0353 | ( -32.69%) |
| Amean | 4 | 5.1663 | 7.6563 | (- 32.52%) |
| Amean | 7 | 8.9180 | 13.3353 | ( -33.13%) |
| Amean | 12 | 15.4290 | 23.0757 | ( -33.14%) |
| Amean | 21 | 27.3333 | 40.7823 | ( -32.98%) |
| Amean | 30 | 38.7677 | 58.5300 | ( -33.76%) |
| Amean | 48 | 62.2987 | 92.9850 | ( -33.00%) |
| Amean | 64 | 82.8993 | 123.4717 | ( -32.86%) |
+-------+----+---------+------------+------------+
Thanks
Jay Patel
>
> It only consists of two patches. Patch #1 addresses inaccuracy in
> SLUB's heuristic, which can negatively affect workloads' performance
> when large folios are not available from buddy.
>
> Patch #2 changes SLUB's behavior when there are no slabs available on
> the
> local node's partial slab list, increasing NUMA locality when there
> are
> available memory (without reclamation) on the local node from buddy.
>
> This is early state, but I think it's a good enough to start
> discussion.
> Any feedbacks and ideas are welcome. Thank you in advance!
>
> Hyeonggon
>
> https://lore.kernel.org/linux-mm/202307172140.3b34825a-oliver.sang@intel.com
> [1]
> https://lore.kernel.org/linux-mm/CAB=+i9S6Ykp90+4N1kCE=hiTJTE4wzJDi8k5pBjjO_3sf0aeqg@mail.gmail.com
> [2]
>
> Hyeonggon Yoo (2):
> Revert "mm, slub: change percpu partial accounting from objects to
> pages"
> mm/slub: prefer NUMA locality over slight memory saving on NUMA
> machines
>
> include/linux/slub_def.h | 2 --
> mm/slab.h | 6 ++++
> mm/slub.c | 76 ++++++++++++++++++++++++++----------
> ----
> 3 files changed, 55 insertions(+), 29 deletions(-)
>
next prev parent reply other threads:[~2023-08-10 10:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-23 19:09 Hyeonggon Yoo
2023-07-23 19:09 ` [RFC 1/2] Revert "mm, slub: change percpu partial accounting from objects to pages" Hyeonggon Yoo
2023-07-26 10:34 ` Vlastimil Babka
2023-08-21 15:11 ` Hyeonggon Yoo
2023-07-23 19:09 ` [RFC 2/2] mm/slub: prefer NUMA locality over slight memory saving on NUMA machines Hyeonggon Yoo
2023-08-03 14:54 ` Vlastimil Babka
2023-08-07 8:39 ` Hyeonggon Yoo
2023-08-08 9:59 ` Vlastimil Babka
2023-08-10 10:55 ` Jay Patel [this message]
2023-08-10 18:06 ` [RFC 0/2] An attempt to improve SLUB on NUMA / under memory pressure Hyeonggon Yoo
2023-08-18 6:45 ` Jay Patel
2023-08-18 15:18 ` Hyeonggon Yoo
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=30b5d85348d84891bf61d7c57370d8b46df8e1a0.camel@linux.ibm.com \
--to=jaypatel@linux.ibm.com \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=cl@linux.com \
--cc=feng.tang@intel.com \
--cc=fengwei.yin@intel.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=merimus@google.com \
--cc=oe-lkp@lists.linux.dev \
--cc=oliver.sang@intel.com \
--cc=penberg@kernel.org \
--cc=piyushs@linux.ibm.com \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=tsahu@linux.ibm.com \
--cc=vbabka@suse.cz \
--cc=ying.huang@intel.com \
/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