| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <ZQEqd6bNOOF9SoWI@chenyu5-mobl2.ccr.corp.intel.com>
Date: Wed, 13 Sep 2023 11:20:23 +0800
From: Chen Yu <yu.c.chen@...el.com>
To: Aaron Lu <aaron.lu@...el.com>
CC: Peter Zijlstra <peterz@...radead.org>,
Vincent Guittot <vincent.guittot@...aro.org>,
Ingo Molnar <mingo@...hat.com>,
"Dietmar Eggemann" <dietmar.eggemann@....com>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
"Gautham R . Shenoy" <gautham.shenoy@....com>,
David Vernet <void@...ifault.com>,
"Nitin Tekchandani" <nitin.tekchandani@...el.com>,
Daniel Jordan <daniel.m.jordan@...cle.com>,
Tim Chen <tim.c.chen@...el.com>,
Swapnil Sapkal <Swapnil.Sapkal@....com>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/1] sched/fair: ratelimit update to tg->load_avg
On 2023-09-12 at 14:58:08 +0800, Aaron Lu wrote:
> When using sysbench to benchmark Postgres in a single docker instance
> with sysbench's nr_threads set to nr_cpu, it is observed there are times
> update_cfs_group() and update_load_avg() shows noticeable overhead on
> a 2sockets/112core/224cpu Intel Sapphire Rapids(SPR):
>
> 13.75% 13.74% [kernel.vmlinux] [k] update_cfs_group
> 10.63% 10.04% [kernel.vmlinux] [k] update_load_avg
>
> Annotate shows the cycles are mostly spent on accessing tg->load_avg
> with update_load_avg() being the write side and update_cfs_group() being
> the read side. tg->load_avg is per task group and when different tasks
> of the same taskgroup running on different CPUs frequently access
> tg->load_avg, it can be heavily contended.
>
> E.g. when running postgres_sysbench on a 2sockets/112cores/224cpus Intel
> Sappire Rapids, during a 5s window, the wakeup number is 14millions and
> migration number is 11millions and with each migration, the task's load
> will transfer from src cfs_rq to target cfs_rq and each change involves
> an update to tg->load_avg. Since the workload can trigger as many wakeups
> and migrations, the access(both read and write) to tg->load_avg can be
> unbound. As a result, the two mentioned functions showed noticeable
> overhead. With netperf/nr_client=nr_cpu/UDP_RR, the problem is worse:
> during a 5s window, wakeup number is 21millions and migration number is
> 14millions; update_cfs_group() costs ~25% and update_load_avg() costs ~16%.
>
> Reduce the overhead by limiting updates to tg->load_avg to at most once
> per ms. The update frequency is a tradeoff between tracking accuracy and
> overhead. 1ms is chosen because PELT window is roughly 1ms and it
> delivered good results for the tests that I've done. After this change,
> the cost of accessing tg->load_avg is greatly reduced and performance
> improved. Detailed test results below.
>
> ==============================
> postgres_sysbench on SPR:
> 25%
> base: 42382±19.8%
> patch: 50174±9.5% (noise)
>
> 50%
> base: 67626±1.3%
> patch: 67365±3.1% (noise)
>
> 75%
> base: 100216±1.2%
> patch: 112470±0.1% +12.2%
>
> 100%
> base: 93671±0.4%
> patch: 113563±0.2% +21.2%
>
> ==============================
> hackbench on ICL:
> group=1
> base: 114912±5.2%
> patch: 117857±2.5% (noise)
>
> group=4
> base: 359902±1.6%
> patch: 361685±2.7% (noise)
>
> group=8
> base: 461070±0.8%
> patch: 491713±0.3% +6.6%
>
> group=16
> base: 309032±5.0%
> patch: 378337±1.3% +22.4%
>
> =============================
> hackbench on SPR:
> group=1
> base: 100768±2.9%
> patch: 103134±2.9% (noise)
>
> group=4
> base: 413830±12.5%
> patch: 378660±16.6% (noise)
>
> group=8
> base: 436124±0.6%
> patch: 490787±3.2% +12.5%
>
> group=16
> base: 457730±3.2%
> patch: 680452±1.3% +48.8%
>
> ============================
> netperf/udp_rr on ICL
> 25%
> base: 114413±0.1%
> patch: 115111±0.0% +0.6%
>
> 50%
> base: 86803±0.5%
> patch: 86611±0.0% (noise)
>
> 75%
> base: 35959±5.3%
> patch: 49801±0.6% +38.5%
>
> 100%
> base: 61951±6.4%
> patch: 70224±0.8% +13.4%
>
> ===========================
> netperf/udp_rr on SPR
> 25%
> base: 104954±1.3%
> patch: 107312±2.8% (noise)
>
> 50%
> base: 55394±4.6%
> patch: 54940±7.4% (noise)
>
> 75%
> base: 13779±3.1%
> patch: 36105±1.1% +162%
>
> 100%
> base: 9703±3.7%
> patch: 28011±0.2% +189%
>
> ==============================================
> netperf/tcp_stream on ICL (all in noise range)
> 25%
> base: 43092±0.1%
> patch: 42891±0.5%
>
> 50%
> base: 19278±14.9%
> patch: 22369±7.2%
>
> 75%
> base: 16822±3.0%
> patch: 17086±2.3%
>
> 100%
> base: 18216±0.6%
> patch: 18078±2.9%
>
> ===============================================
> netperf/tcp_stream on SPR (all in noise range)
> 25%
> base: 34491±0.3%
> patch: 34886±0.5%
>
> 50%
> base: 19278±14.9%
> patch: 22369±7.2%
>
> 75%
> base: 16822±3.0%
> patch: 17086±2.3%
>
> 100%
> base: 18216±0.6%
> patch: 18078±2.9%
>
> Reported-by: Nitin Tekchandani <nitin.tekchandani@...el.com>
> Suggested-by: Vincent Guittot <vincent.guittot@...aro.org>
> Signed-off-by: Aaron Lu <aaron.lu@...el.com>
> Reviewed-by: Vincent Guittot <vincent.guittot@...aro.org>
> Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
> Tested-by: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
> Reviewed-by: David Vernet <void@...ifault.com>
> Tested-by: Swapnil Sapkal <Swapnil.Sapkal@....com>
> ---
>
Since we know that this patch brings good improvement for netperf,
hackbench, I did some further verification on tbench/schbench on Ice Lake
Xeon Platinum 8360Y, and it reports good result too:
schbench
========
case load baseline(std%) compare%( std%)
normal 1-mthreads 1.00 ( 1.70) +0.00 ( 0.00)
normal 2-mthreads 1.00 ( 2.32) -0.62 ( 5.24)
normal 4-mthreads 1.00 ( 3.17) -1.86 ( 3.11)
tbench
======
case load baseline(std%) compare%( std%)
loopback 36-threads 1.00 ( 2.80) +1.85 ( 0.45)
loopback 72-threads 1.00 ( 0.27) -0.20 ( 0.51)
loopback 108-threads 1.00 ( 0.06) +21.92 ( 0.10)
loopback 144-threads 1.00 ( 1.47) +28.42 ( 0.11)
Tested-by: Chen Yu <yu.c.chen@...el.com>
thanks,
Chenyu
Powered by blists - more mailing lists