From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> To: Georgi Djakov <djakov@kernel.org>, Andy Gross <agross@kernel.org>, Bjorn Andersson <bjorn.andersson@linaro.org>, Rob Herring <robh+dt@kernel.org>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, linux-arm-msm@vger.kernel.org, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: Thara Gopinath <thara.gopinath@linaro.org> Subject: Re: [PATCH v4 4/4] arm64: dts: qcom: sdm845: Add CPU BWMON Date: Tue, 7 Jun 2022 08:48:03 +0200 [thread overview] Message-ID: <e5029de5-2548-23a4-8dcf-101154e0be29@linaro.org> (raw) In-Reply-To: <058de46e-24cf-e25b-121c-3ff080702776@kernel.org> On 06/06/2022 22:39, Georgi Djakov wrote: > On 1.06.22 13:11, Krzysztof Kozlowski wrote: >> Add device node for CPU-memory BWMON device (bandwidth monitoring) on >> SDM845 measuring bandwidth between CPU (gladiator_noc) and Last Level >> Cache (memnoc). Usage of this BWMON allows to remove fixed bandwidth >> votes from cpufreq (CPU nodes) thus achieve high memory throughput even >> with lower CPU frequencies. >> >> Performance impact (SDM845-MTP RB3 board, linux next-20220422): >> 1. No noticeable impact when running with schedutil or performance >> governors. >> >> 2. When comparing to customized kernel with synced interconnects and >> without bandwidth votes from CPU freq, the sysbench memory tests >> show significant improvement with bwmon for blocksizes past the L3 >> cache. The results for such superficial comparison: >> >> sysbench memory test, results in MB/s (higher is better) >> bs kB | type | V | V+no bw votes | bwmon | benefit % >> 1 | W/seq | 14795 | 4816 | 4985 | 3.5% >> 64 | W/seq | 41987 | 10334 | 10433 | 1.0% >> 4096 | W/seq | 29768 | 8728 | 32007 | 266.7% >> 65536 | W/seq | 17711 | 4846 | 18399 | 279.6% >> 262144 | W/seq | 16112 | 4538 | 17429 | 284.1% >> 64 | R/seq | 61202 | 67092 | 66804 | -0.4% >> 4096 | R/seq | 23871 | 5458 | 24307 | 345.4% >> 65536 | R/seq | 18554 | 4240 | 18685 | 340.7% >> 262144 | R/seq | 17524 | 4207 | 17774 | 322.4% >> 64 | W/rnd | 2663 | 1098 | 1119 | 1.9% >> 65536 | W/rnd | 600 | 316 | 610 | 92.7% >> 64 | R/rnd | 4915 | 4784 | 4594 | -4.0% >> 65536 | R/rnd | 664 | 281 | 678 | 140.7% >> >> Legend: >> bs kB: block size in KB (small block size means only L1-3 caches are >> used >> type: R - read, W - write, seq - sequential, rnd - random >> V: vanilla (next-20220422) >> V + no bw votes: vanilla without bandwidth votes from CPU freq >> bwmon: bwmon without bandwidth votes from CPU freq >> benefit %: difference between vanilla without bandwidth votes and bwmon >> (higher is better) >> > > Ok, now i see! So bwmon shows similar performance compared with the current > cpufreq-based bandwidth scaling. And if you add bwmon on top of vanilla, are > the results close/same? Vanilla + bwmon results in almost no difference. > Is the plan to remove the cpufreq based bandwidth > scaling and switch to bwmon? It might improve the power consumption in some > scenarios. The next plan would be to implement the second bwmon, one between CPU and caches. With both of them, the cpufreq bandwidth votes can be removed (I think Android might be interested in this). Best regards, Krzysztof
WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> To: Georgi Djakov <djakov@kernel.org>, Andy Gross <agross@kernel.org>, Bjorn Andersson <bjorn.andersson@linaro.org>, Rob Herring <robh+dt@kernel.org>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, linux-arm-msm@vger.kernel.org, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: Thara Gopinath <thara.gopinath@linaro.org> Subject: Re: [PATCH v4 4/4] arm64: dts: qcom: sdm845: Add CPU BWMON Date: Tue, 7 Jun 2022 08:48:03 +0200 [thread overview] Message-ID: <e5029de5-2548-23a4-8dcf-101154e0be29@linaro.org> (raw) In-Reply-To: <058de46e-24cf-e25b-121c-3ff080702776@kernel.org> On 06/06/2022 22:39, Georgi Djakov wrote: > On 1.06.22 13:11, Krzysztof Kozlowski wrote: >> Add device node for CPU-memory BWMON device (bandwidth monitoring) on >> SDM845 measuring bandwidth between CPU (gladiator_noc) and Last Level >> Cache (memnoc). Usage of this BWMON allows to remove fixed bandwidth >> votes from cpufreq (CPU nodes) thus achieve high memory throughput even >> with lower CPU frequencies. >> >> Performance impact (SDM845-MTP RB3 board, linux next-20220422): >> 1. No noticeable impact when running with schedutil or performance >> governors. >> >> 2. When comparing to customized kernel with synced interconnects and >> without bandwidth votes from CPU freq, the sysbench memory tests >> show significant improvement with bwmon for blocksizes past the L3 >> cache. The results for such superficial comparison: >> >> sysbench memory test, results in MB/s (higher is better) >> bs kB | type | V | V+no bw votes | bwmon | benefit % >> 1 | W/seq | 14795 | 4816 | 4985 | 3.5% >> 64 | W/seq | 41987 | 10334 | 10433 | 1.0% >> 4096 | W/seq | 29768 | 8728 | 32007 | 266.7% >> 65536 | W/seq | 17711 | 4846 | 18399 | 279.6% >> 262144 | W/seq | 16112 | 4538 | 17429 | 284.1% >> 64 | R/seq | 61202 | 67092 | 66804 | -0.4% >> 4096 | R/seq | 23871 | 5458 | 24307 | 345.4% >> 65536 | R/seq | 18554 | 4240 | 18685 | 340.7% >> 262144 | R/seq | 17524 | 4207 | 17774 | 322.4% >> 64 | W/rnd | 2663 | 1098 | 1119 | 1.9% >> 65536 | W/rnd | 600 | 316 | 610 | 92.7% >> 64 | R/rnd | 4915 | 4784 | 4594 | -4.0% >> 65536 | R/rnd | 664 | 281 | 678 | 140.7% >> >> Legend: >> bs kB: block size in KB (small block size means only L1-3 caches are >> used >> type: R - read, W - write, seq - sequential, rnd - random >> V: vanilla (next-20220422) >> V + no bw votes: vanilla without bandwidth votes from CPU freq >> bwmon: bwmon without bandwidth votes from CPU freq >> benefit %: difference between vanilla without bandwidth votes and bwmon >> (higher is better) >> > > Ok, now i see! So bwmon shows similar performance compared with the current > cpufreq-based bandwidth scaling. And if you add bwmon on top of vanilla, are > the results close/same? Vanilla + bwmon results in almost no difference. > Is the plan to remove the cpufreq based bandwidth > scaling and switch to bwmon? It might improve the power consumption in some > scenarios. The next plan would be to implement the second bwmon, one between CPU and caches. With both of them, the cpufreq bandwidth votes can be removed (I think Android might be interested in this). Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-06-07 6:48 UTC|newest] Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-06-01 10:11 [PATCH v4 0/4] soc/arm64: qcom: Add initial version of bwmon Krzysztof Kozlowski 2022-06-01 10:11 ` Krzysztof Kozlowski 2022-06-01 10:11 ` [PATCH v4 1/4] dt-bindings: interconnect: qcom,sdm845-cpu-bwmon: add BWMON device Krzysztof Kozlowski 2022-06-01 10:11 ` Krzysztof Kozlowski 2022-06-06 21:11 ` Bjorn Andersson 2022-06-06 21:11 ` Bjorn Andersson 2022-06-07 6:50 ` Krzysztof Kozlowski 2022-06-07 6:50 ` Krzysztof Kozlowski 2022-06-22 11:58 ` Rajendra Nayak 2022-06-22 11:58 ` Rajendra Nayak 2022-06-22 12:20 ` Krzysztof Kozlowski 2022-06-22 12:20 ` Krzysztof Kozlowski 2022-06-26 3:19 ` Bjorn Andersson 2022-06-26 3:19 ` Bjorn Andersson 2022-06-28 10:43 ` Rajendra Nayak 2022-06-28 10:43 ` Rajendra Nayak 2022-06-01 10:11 ` [PATCH v4 2/4] soc: qcom: icc-bwmon: Add bandwidth monitoring driver Krzysztof Kozlowski 2022-06-01 10:11 ` Krzysztof Kozlowski 2022-06-06 16:35 ` Georgi Djakov 2022-06-06 16:35 ` Georgi Djakov 2022-06-01 10:11 ` [PATCH v4 3/4] arm64: defconfig: enable Qualcomm Bandwidth Monitor Krzysztof Kozlowski 2022-06-01 10:11 ` Krzysztof Kozlowski 2022-06-01 10:11 ` [PATCH v4 4/4] arm64: dts: qcom: sdm845: Add CPU BWMON Krzysztof Kozlowski 2022-06-01 10:11 ` Krzysztof Kozlowski 2022-06-06 20:39 ` Georgi Djakov 2022-06-06 20:39 ` Georgi Djakov 2022-06-07 6:48 ` Krzysztof Kozlowski [this message] 2022-06-07 6:48 ` Krzysztof Kozlowski 2022-06-22 11:46 ` Rajendra Nayak 2022-06-22 11:46 ` Rajendra Nayak 2022-06-22 13:52 ` Krzysztof Kozlowski 2022-06-22 13:52 ` Krzysztof Kozlowski 2022-06-23 6:48 ` Rajendra Nayak 2022-06-23 6:48 ` Rajendra Nayak 2022-06-23 12:58 ` Krzysztof Kozlowski 2022-06-23 12:58 ` Krzysztof Kozlowski 2022-06-26 3:28 ` Bjorn Andersson 2022-06-26 3:28 ` Bjorn Andersson 2022-06-27 12:39 ` Krzysztof Kozlowski 2022-06-27 12:39 ` Krzysztof Kozlowski 2022-06-28 10:36 ` Rajendra Nayak 2022-06-28 10:36 ` Rajendra Nayak 2022-06-28 10:50 ` Krzysztof Kozlowski 2022-06-28 10:50 ` Krzysztof Kozlowski 2022-06-28 13:15 ` Rajendra Nayak 2022-06-28 13:15 ` Rajendra Nayak 2022-06-28 14:02 ` Krzysztof Kozlowski 2022-06-28 14:02 ` Krzysztof Kozlowski 2022-06-28 15:20 ` Rajendra Nayak 2022-06-28 15:20 ` Rajendra Nayak 2022-06-28 15:23 ` Krzysztof Kozlowski 2022-06-28 15:23 ` Krzysztof Kozlowski
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=e5029de5-2548-23a4-8dcf-101154e0be29@linaro.org \ --to=krzysztof.kozlowski@linaro.org \ --cc=agross@kernel.org \ --cc=bjorn.andersson@linaro.org \ --cc=catalin.marinas@arm.com \ --cc=devicetree@vger.kernel.org \ --cc=djakov@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=robh+dt@kernel.org \ --cc=thara.gopinath@linaro.org \ --cc=will@kernel.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.