From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7BC03C43334 for ; Tue, 7 Jun 2022 06:53:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=e0E6czfLIlY39mPRWt56NgD3C8D+RlTX0v5rtqic7hQ=; b=e8bmwQFldN/6DV EM3r/r4uunyvImBDT0KAi/sHMclfbA4Z9Gk/gglzQd70frWo+JJirlUg4Z5IlB8sTGavj9NCiEYDT xYSdMZ11lgvRu0Z1SqynmuRFVdjEj55oKxB2If5VOnGNCfjM7Hq4/eJuEdMcmN586xg4VACOX5Udb b/vx7GPuxN7klRlmSETrElimaQc7c32rmdAKEIW6k07MEagfmpiruq0I1ZXSdsheNljUMIasDL/bV qBMJYUu4kTSRXLt9AgJQtUW72vB1IFOUfWgg1/B6BWjJPleviQhoTc+di5rxqgieL41yJjny8K4Hi bWzydkwYbilKmJqa4z7g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nyT4h-005Cm8-3c; Tue, 07 Jun 2022 06:52:25 +0000 Received: from mail-ej1-x636.google.com ([2a00:1450:4864:20::636]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nyT0Z-005A7c-30 for linux-arm-kernel@lists.infradead.org; Tue, 07 Jun 2022 06:48:08 +0000 Received: by mail-ej1-x636.google.com with SMTP id kq6so20146189ejb.11 for ; Mon, 06 Jun 2022 23:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=9oONL/OIu1tsLLfjz8MWbADwzFR0KPOH6QzNxFIcw1A=; b=eHc01tNuGgQVe9JfPpB6GYMNwZK46sRHR3uDq807BB8RAkhtM9iR1guy6gYb+UKuJW g3yAm4q1CjZJ6Pp9OZfINnQzQ6SlfDARMFL44cz7rzQyewKJDz4DCw2s9a6+PUnsnsls kkbjZQKYC5uzVhSvIW60DvmNZwSNXhTnEDamP2tQK2CG6zybiBXQOP8biOwIXxqLd/lr xXp4GE/l02zl0EyPtU9/au8J7ZOL5nvjMry9t1lUMfnAAiEl5h/aERCGNL3NcZMtNr6W z9u/tnTpAuY5gaFcEPQ2vdavW7L3MZwzsFofi2wXD9QrtStZ8mfDytt2Wi/3dZ3/NivE FNhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=9oONL/OIu1tsLLfjz8MWbADwzFR0KPOH6QzNxFIcw1A=; b=L6ckikaaN1/JczyyAr1c/raS/X4VuumXE1VBBAzCOAK0tFBMohkKToUa9ywADEcZIM v56iPBQUFYteCyQ0M1JfZI/nMNolG132a1+D3k0Cv+0q2kft1TG0pfgDeOuDQoJSsxAG hY3PBaOO/LSTop7yM7B/1lpZPxofRymVf7E7CWsRZMTLd/P70hrXt/cBHau2yMm676RA jzT1Kz/67ZRHucsAgSBwQau3HvredAJhSAw8DEHEi3ngLBqAcLHRvtCHshbk0LVoqbgB XqxwC+7AJxaSwzRnsUN41guWV1jznk1eycWZQh29v1z6dRPPfhGkJ7tnFTnYbx5NbYHS Himw== X-Gm-Message-State: AOAM530MXa9ynAmKR9mJyK+yx5DUGXTjXHjLojlCmRoRleDEn4Uv5cIL 1TfHXxw22fBbcbUnIlYBg9CYPA== X-Google-Smtp-Source: ABdhPJwZ+u3wskAK8md9FAIw+OFZWkxhbfQb/zXoi4kIC5wHI/eBNsIRDkNmc9Xh8XtL7N+ZNnWZaw== X-Received: by 2002:a17:907:3d89:b0:6f9:1fc:ebf3 with SMTP id he9-20020a1709073d8900b006f901fcebf3mr25319012ejc.403.1654584485575; Mon, 06 Jun 2022 23:48:05 -0700 (PDT) Received: from [192.168.0.181] (xdsl-188-155-176-92.adslplus.ch. [188.155.176.92]) by smtp.gmail.com with ESMTPSA id d20-20020aa7ce14000000b0042dd4ccccf5sm9653874edv.82.2022.06.06.23.48.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Jun 2022 23:48:05 -0700 (PDT) Message-ID: Date: Tue, 7 Jun 2022 08:48:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH v4 4/4] arm64: dts: qcom: sdm845: Add CPU BWMON Content-Language: en-US To: Georgi Djakov , Andy Gross , Bjorn Andersson , Rob Herring , Catalin Marinas , Will Deacon , 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 References: <20220601101140.170504-1-krzysztof.kozlowski@linaro.org> <20220601101140.170504-5-krzysztof.kozlowski@linaro.org> <058de46e-24cf-e25b-121c-3ff080702776@kernel.org> From: Krzysztof Kozlowski In-Reply-To: <058de46e-24cf-e25b-121c-3ff080702776@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220606_234807_196911_9359CF7E X-CRM114-Status: GOOD ( 16.81 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.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