[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20220722162257.bl5zhc7ta6jvuy5e@google.com>
Date: Fri, 22 Jul 2022 16:22:57 +0000
From: Shakeel Butt <shakeelb@...gle.com>
To: Jiebin Sun <jiebin.sun@...el.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
cgroups@...r.kernel.org, hannes@...xchg.org, mhocko@...nel.org,
roman.gushchin@...ux.dev, songmuchun@...edance.com,
akpm@...ux-foundation.org, tim.c.chen@...el.com,
ying.huang@...el.com, amadeuszx.slawinski@...ux.intel.com,
tianyou.li@...el.com, wangyang.guo@...el.com
Subject: Re: [PATCH] mm: Remove the redundant updating of stats_flush_threshold
On Sat, Jul 23, 2022 at 12:49:49AM +0800, Jiebin Sun wrote:
> From: jiebin sun <jiebin.sun@...el.com>
>
> Remove the redundant updating of stats_flush_threshold. If the
> global var stats_flush_threshold has exceeded the trigger value
> for __mem_cgroup_flush_stats, further increment is unnecessary.
>
> Apply the patch and test the pts/hackbench-1.0.0 Count:4 (160 threads).
>
> Score gain: 1.95x
> Reduce CPU cycles in __mod_memcg_lruvec_state (44.88% -> 0.12%)
>
> CPU: ICX 8380 x 2 sockets
> Core number: 40 x 2 physical cores
> Benchmark: pts/hackbench-1.0.0 Count:4 (160 threads)
>
> Signed-off-by: Jiebin Sun <jiebin.sun@...el.com>
Yes, this makes sense. No need to dirty a cacheline if we are already
over the threshold.
Acked-by: Shakeel Butt <shakeelb@...gle.com>
Powered by blists - more mailing lists