[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20220905193516.846647-1-jiebin.sun@intel.com>
Date: Tue, 6 Sep 2022 03:35:14 +0800
From: Jiebin Sun <jiebin.sun@...el.com>
To: akpm@...ux-foundation.org, vasily.averin@...ux.dev,
shakeelb@...gle.com, dennis@...nel.org, tj@...nel.org,
cl@...ux.com, ebiederm@...ssion.com, legion@...nel.org,
manfred@...orfullife.com, alexander.mikhalitsyn@...tuozzo.com,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Cc: tim.c.chen@...el.com, feng.tang@...el.com, ying.huang@...el.com,
tianyou.li@...el.com, wangyang.guo@...el.com, jiebin.sun@...el.com
Subject: [PATCH v2 0/2] ipc/msg: mitigate the lock contention in ipc/msg
Hi,
Here are two patches to mitigate the lock contention in ipc/msg.
The 1st patch is to add the new function percpu_counter_add_local if
only update the local counter without aggregating to global counter.
The 2nd patch is to use percpu_counter_add_local instead of atomic
updating in do_msgsnd and do_msgrcv every time. It will always do
sum when the syscall msgctl_info. So there is no need to do global
adding in percpu_counter_add_batch. We add percpu_counter_add_local
to resolve the above issue. The sum operation in msgctl_info is
infrequent and the additional cost is much less compared to the
performance gain in do_msgsnd and do_msgrcv.
Changes in v2:
1. Separate the original patch into two patches.
2. Add error handling for percpu_counter_init.
The performance gain increases as the threads of workload become larger.
Performance gain: 3.38x
CPU: ICX 8380 x 2 sockets
Core number: 40 x 2 physical cores
Benchmark: pts/stress-ng-1.4.0
-- system v message passing (160 threads)
Regards
Jiebin
Powered by blists - more mailing lists