Thread (19 messages) 19 messages, 6 authors, 2021-01-06

Re: [PATCH 1/2] mm: page_counter: relayout structure to reduce false sharing

From: Feng Tang <hidden>
Date: 2021-01-04 14:44:49
Also in: lkml

On Mon, Jan 04, 2021 at 03:11:40PM +0100, Michal Hocko wrote:
On Mon 04-01-21 21:34:45, Feng Tang wrote:
quoted
Hi Michal,

On Mon, Jan 04, 2021 at 02:03:57PM +0100, Michal Hocko wrote:
quoted
On Tue 29-12-20 22:35:13, Feng Tang wrote:
quoted
When checking a memory cgroup related performance regression [1],
from the perf c2c profiling data, we found high false sharing for
accessing 'usage' and 'parent'.

On 64 bit system, the 'usage' and 'parent' are close to each other,
and easy to be in one cacheline (for cacheline size == 64+ B). 'usage'
is usally written, while 'parent' is usually read as the cgroup's
hierarchical counting nature.

So move the 'parent' to the end of the structure to make sure they
are in different cache lines.
Yes, parent is write-once field so having it away from other heavy RW
fields makes sense to me.
 
quoted
Following are some performance data with the patch, against
v5.11-rc1, on several generations of Xeon platforms. Most of the
results are improvements, with only one malloc case on one platform
shows a -4.0% regression. Each category below has several subcases
run on different platform, and only the worst and best scores are
listed:

fio:				 +1.8% ~  +8.3%
will-it-scale/malloc1:		 -4.0% ~  +8.9%
will-it-scale/page_fault1:	 no change
will-it-scale/page_fault2:	 +2.4% ~  +20.2%
What is the second number? Std?
For each case like 'page_fault2', I run several subcases on different
generations of Xeon, and only listed the lowest (first number) and
highest (second number) scores.

There are 5 runs and the result are: +3.6%, +2.4%, +10.4%, +20.2%,
+4.7%, and +2.4% and +20.2% are listed.
This should be really explained in the changelog and ideally mention the
model as well. Seeing a std would be appreciated as well.
I guess I haven't made it clear (due to my poor English :))

The five scores are for different parameters on different HW:

Cascadelake (100%)    77844    +3.6%    80667   will-it-scale.per_process_ops
Cascadelake  (50%)   182475    +2.4%   186866   will-it-scale.per_process_ops
Haswell     (100%)    84870   +10.4%    93671   will-it-scale.per_process_ops
Haswell      (50%)   197684   +20.2%   237585   will-it-scale.per_process_ops
Newer Xeon   (50%)   268569    +4.7%   281320   will-it-scale.per_process_ops

+2.4% is the lowest improvement, while +20.2% is the highest. 

100% means the number of forked test processes eqauls to CPU number,
while 50% is the half. Each line has been runed several times, whose score
are consistent without big deviations.

Thanks,
Feng




Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help