| Message ID | 20200708153420.29484-1-lukasz.luba@arm.com (mailing list archive) |
|---|---|
| Headers | show
Return-Path: <SRS0=EHji=AT=lists.infradead.org=linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@kernel.org> Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 24AF314E3 for <patchwork-linux-arm@patchwork.kernel.org>; Wed, 8 Jul 2020 15:36:33 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E1E8B206DF for <patchwork-linux-arm@patchwork.kernel.org>; Wed, 8 Jul 2020 15:36:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="PfN9d29a" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E1E8B206DF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:MIME-Version:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-Id:Date:Subject:To:From:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Owner; bh=0M/nUKv06YFEpGtIHZcadHfOkgMLbfbLYSrgX7l9DH8=; b=PfN9d29aJcFdaHoDApH8NWazWu N2dp1pKadaV5QOWujOpHmQtz5liw00DikQhEprTAhqFZeQzf/bSeibnA9BT+u1gtgEaPLjofSZmmM KQcWGxHZiMVc/XUVucfE+LFpx78sQ36khFw/qDxDsbGHASHfhslRTXZtzqbNf9h2PJtWLOspag8el WtrV3pseXGIfJtcyaSSfIDYkngFzr6jg4zPojcwY2iAfSZjgffquf+74z9cnqEO1xnQZfQ2aQCF9+ LG48GWviAO1KRqJkHKf8F5JIf4IJAtpkDKbuoS+pHs1OwOqHJlWycvwsF+LK9sBf4GjVEmU3kHTvm CKZ6Zl/Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jtC5t-0005Z7-C0; Wed, 08 Jul 2020 15:34:45 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jtC5p-0005Xk-3b for linux-arm-kernel@lists.infradead.org; Wed, 08 Jul 2020 15:34:42 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 36C211045; Wed, 8 Jul 2020 08:34:40 -0700 (PDT) Received: from e123648.arm.com (unknown [10.37.12.67]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 2FBCE3F237; Wed, 8 Jul 2020 08:34:36 -0700 (PDT) From: Lukasz Luba <lukasz.luba@arm.com> To: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org Subject: [PATCH 0/2] Exynos5422 DMC: adjust to new devfreq monitoring mechanism Date: Wed, 8 Jul 2020 16:34:18 +0100 Message-Id: <20200708153420.29484-1-lukasz.luba@arm.com> X-Mailer: git-send-email 2.17.1 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200708_113441_325287_0F72C0AE X-CRM114-Status: GOOD ( 14.25 ) X-Spam-Score: -2.3 (--) X-Spam-Report: SpamAssassin version 3.4.4 on merlin.infradead.org summary: Content analysis details: (-2.3 points) pts rule name description ---- ---------------------- -------------------------------------------------- -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/, medium trust [217.140.110.172 listed in list.dnswl.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: <linux-arm-kernel.lists.infradead.org> List-Unsubscribe: <http://lists.infradead.org/mailman/options/linux-arm-kernel>, <mailto:linux-arm-kernel-request@lists.infradead.org?subject=unsubscribe> List-Archive: <http://lists.infradead.org/pipermail/linux-arm-kernel/> List-Post: <mailto:linux-arm-kernel@lists.infradead.org> List-Help: <mailto:linux-arm-kernel-request@lists.infradead.org?subject=help> List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-arm-kernel>, <mailto:linux-arm-kernel-request@lists.infradead.org?subject=subscribe> Cc: s.nawrocki@samsung.com, b.zolnierkie@samsung.com, k.konieczny@samsung.com, krzk@kernel.org, cw00.choi@samsung.com, kyungmin.park@samsung.com, willy.mh.wolff.ml@gmail.com, myungjoo.ham@samsung.com, chanwoo@kernel.org, kgene@kernel.org, lukasz.luba@arm.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" <linux-arm-kernel-bounces@lists.infradead.org> Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org |
| Series |
Exynos5422 DMC: adjust to new devfreq monitoring mechanism
|
expand
|
Hi all, There have been discussions around devfreq, it's related drivers and governors, reporting some issues [1][2]. There are a patch sets trying to address these issues [2][3], discussion is still ongoing. This patch set is a follow up for changes presented in [2]. It moves from internal interrupts to devfreq monitoring mechanism with fixed polling interval in the memory controller. The value of polling and uptreshold have been adjusted in order to get better reaction in the benchmark workload [4]. The test workload is specific and I still have to spend some more time to understand impact of different CPUs or different utilization and governor's decisions. Now, with the patches it looks better. For other future adjustments, not specific to a particular driver's code, I would rather see a different mechanism, which I'll post shortly as an RFC. The patch 1/2 needs [2] series, while the patch 2/2 is on top of Krzysztof's today next/dt branch [5] (I assume patch 2/2 would go through his tree). Here are test results for the benchmark from [4], showing some more accurate reaction for the benchmark workload (gentle ask to Willy to confirm this): simple_ondlemand: littles: 1.40374 s (was 4.74308 s) bigs: 1.44519 s (was 4.76556 s) performance: littles: 1.13635 s bigs: 1.17349 s -------------------------------8<-------------------------------- oller/trans_stat /odroid/benchmark# cat /sys/class/devfreq/10c20000.memory-contro From : To : 165000000 206000000 275000000 413000000 543000000 633000000 728000000 825000000 time(ms) * 165000000: 0 15 24 13 12 2 0 11 1128580 206000000: 12 0 8 7 3 1 0 0 3760 275000000: 17 8 0 12 10 2 0 5 6340 413000000: 19 5 9 0 7 5 0 9 10290 543000000: 18 0 6 13 0 31 1 8 7510 633000000: 4 3 3 6 27 0 0 1 11440 728000000: 1 0 0 0 0 0 0 0 110 825000000: 7 0 4 3 18 3 0 0 23490 Total transition : 373 root@odroid:/home/odroid/benchmark# bash source/scripts/test_dvfs_mem.sh mem_gov = simple_ondemand at 413000000 From : To : 165000000 206000000 275000000 413000000 543000000 633000000 728000000 825000000 time(ms) 165000000: 0 15 26 14 12 2 0 11 1134220 206000000: 12 0 8 7 3 1 0 0 3760 275000000: 18 8 0 13 10 2 0 5 6670 * 413000000: 20 5 9 0 7 5 0 9 10460 543000000: 18 0 6 13 0 31 1 8 7510 633000000: 4 3 3 6 27 0 0 1 11440 728000000: 1 0 0 0 0 0 0 0 110 825000000: 7 0 4 3 18 3 0 0 23490 Total transition : 379 Running on the LITTLE cluster array_size rounded to fit a CACHE_LINE_SIZE from 33554431 to 33554432 sizeof(size_t) = 4 array_size = 33554432 ==> 134217728 b; 131072 Kb; 128 Mb stride = 0 nr_iter = 9722222 nr_iter_2 = 1 effective_nr_iter = 9722222 cpu_freq = 1400000 ==> 1.4 GHz; 1400 MHz; 1400000 KHz total time = 1403736317 ns; 1.40374 s time per iter 144.384 ns estimated cycles per iter 202.138 c Running on the big cluster array_size rounded to fit a CACHE_LINE_SIZE from 33554431 to 33554432 sizeof(size_t) = 4 array_size = 33554432 ==> 134217728 b; 131072 Kb; 128 Mb stride = 0 nr_iter = 9722222 nr_iter_2 = 1 effective_nr_iter = 9722222 cpu_freq = 2000000 ==> 2 GHz; 2000 MHz; 2000000 KHz total time = 1445186489 ns; 1.44519 s time per iter 148.648 ns estimated cycles per iter 297.296 c From : To : 165000000 206000000 275000000 413000000 543000000 633000000 728000000 825000000 time(ms) 165000000: 0 15 26 14 12 2 0 11 1134220 206000000: 12 0 8 7 3 1 0 0 3760 275000000: 18 8 0 13 15 2 0 5 7220 413000000: 20 5 10 0 7 5 0 9 10510 543000000: 18 0 10 13 0 32 1 9 8280 * 633000000: 4 3 3 6 28 0 0 1 14160 728000000: 1 0 0 0 0 0 0 0 110 825000000: 7 0 4 3 18 4 0 0 23930 Total transition : 393 mem_gov = performance at 825000000 From : To : 165000000 206000000 275000000 413000000 543000000 633000000 728000000 825000000 time(ms) 165000000: 0 15 26 14 12 2 0 11 1134220 206000000: 12 0 8 7 3 1 0 0 3760 275000000: 18 8 0 13 15 2 0 6 7300 413000000: 20 5 10 0 7 5 0 9 10510 543000000: 18 0 10 13 0 32 1 9 8280 633000000: 4 3 4 6 28 0 0 1 14190 728000000: 1 0 0 0 0 0 0 0 110 * 825000000: 7 0 4 3 18 4 0 0 23980 Total transition : 395 Running on the LITTLE cluster array_size rounded to fit a CACHE_LINE_SIZE from 33554431 to 33554432 sizeof(size_t) = 4 array_size = 33554432 ==> 134217728 b; 131072 Kb; 128 Mb stride = 0 nr_iter = 9722222 nr_iter_2 = 1 effective_nr_iter = 9722222 cpu_freq = 1400000 ==> 1.4 GHz; 1400 MHz; 1400000 KHz total time = 1136350257 ns; 1.13635 s time per iter 116.882 ns estimated cycles per iter 163.634 c Running on the big cluster array_size rounded to fit a CACHE_LINE_SIZE from 33554431 to 33554432 sizeof(size_t) = 4 array_size = 33554432 ==> 134217728 b; 131072 Kb; 128 Mb stride = 0 nr_iter = 9722222 nr_iter_2 = 1 effective_nr_iter = 9722222 cpu_freq = 2000000 ==> 2 GHz; 2000 MHz; 2000000 KHz total time = 1173486470 ns; 1.17349 s time per iter 120.701 ns estimated cycles per iter 241.403 c From : To : 165000000 206000000 275000000 413000000 543000000 633000000 728000000 825000000 time(ms) 165000000: 0 15 26 14 12 2 0 11 1134220 206000000: 12 0 8 7 3 1 0 0 3760 275000000: 18 8 0 13 15 2 0 6 7300 413000000: 20 5 10 0 7 5 0 9 10510 543000000: 18 0 10 13 0 32 1 9 8280 633000000: 4 3 4 6 28 0 0 1 14190 728000000: 1 0 0 0 0 0 0 0 110 * 825000000: 7 0 4 3 18 4 0 0 27760 Total transition : 395 root@odroid:/home/odroid/benchmark# oller/trans_stat /odroid/benchmark# cat /sys/class/devfreq/10c20000.memory-contro From : To : 165000000 206000000 275000000 413000000 543000000 633000000 728000000 825000000 time(ms) * 165000000: 0 15 26 14 12 2 0 11 1138930 206000000: 12 0 8 7 3 1 0 0 3760 275000000: 18 8 0 13 15 2 0 6 7300 413000000: 20 5 10 0 7 5 0 9 10510 543000000: 19 0 10 13 0 32 1 9 8390 633000000: 4 3 4 6 28 0 0 1 14190 728000000: 1 0 0 0 0 0 0 0 110 825000000: 7 0 4 3 19 4 0 0 28280 Total transition : 397 root@odroid:/home/odroid/benchmark# ----------------------------------------->8-------------------------------------------- Regards, Lukasz Luba [1] https://lore.kernel.org/linux-pm/20200623164733.qbhua7b6cg2umafj@macmini.local/ [2] https://lore.kernel.org/linux-pm/20200703062622.11773-1-cw00.choi@samsung.com/ [3] https://lore.kernel.org/linux-pm/20200703100810.12304-1-cw00.choi@samsung.com/ [4] https://github.com/wwilly/benchmark.git [5] https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git/log/?h=next/dt Lukasz Luba (2): memory: samsung: exynos5422-dmc: Adjust polling interval and uptreshold ARM: dts: exynos: Remove interrupts from DMC controller in Exynos5422 arch/arm/boot/dts/exynos5420.dtsi | 3 --- drivers/memory/samsung/exynos5422-dmc.c | 4 ++-- 2 files changed, 2 insertions(+), 5 deletions(-)