Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp3848472ybt; Tue, 23 Jun 2020 12:14:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyQZb1x7gdhCwcieD/kS9f8ILj88vii904eog5eMl9BfsIRSG/XpYrzem2hB4e0rRec0YSB X-Received: by 2002:a50:aca6:: with SMTP id x35mr2844170edc.328.1592939681900; Tue, 23 Jun 2020 12:14:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592939681; cv=none; d=google.com; s=arc-20160816; b=jf6RhQxW4X8QOyCO0BdcyKCqXD7GxHexKiy6lFVPD1tBTy0CZJd4dmlW7mgFa+489V Apup1DiyCKeZyEaWr/atH8feqBZr1an+a17aCzfxApIm4oH/pvUIPJIHOB4EKj2A/w3v z7W2YeDXsXxsiI99ydOGYYEwlQQCMCY28REC4TXSlhsw0JMuYodnB/3QBjfHTN3tSuae WUVLYbKBUfl/ZKNn9FRpk1IhJmCUQ7vHzhKu/CF4p2bFjcHOVjyvkH7KAVsW+X4b90WD p19gBKfPtSbgs7MzgOJ/IBmT7r5KKQ91NsMMvWZ/DMWRk4dLfu+mWvy8ZvLk0q1ig29Q UHhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=S6qzk+OKExXb2YpLZeuh1PmKG+c4jm0lpjuoeWwXFzk=; b=zUXtEbB3DNC39fyPDkXTQP0JuT3wxx833CEsF0DuvwJoMNhb/LHg23C/yhc/ZUY2U5 L0KFnyuOUZ932g/MBl1ekAknC7AZGb80S48Ll0FApltXW2HI53lvRDuSmm1aV5kQ62qH KcybOS/LDbhLov4y2yigvm2amYjb0XVbtQUZbbe22CBZBMe92V0FjnR7NkwoUqMEHpzs qcYFm5VRGo4DUPbu6z2hihCpGRQ7nRztOQJKfedr1xC4HJ6088bD0Xbg5WQIH0VKYmKQ sn0SSEb+Fvqh1vPLuN6fWRj2MYFCuRTxmDTwU1ALQ1C2vVesXvhtQC9k7JoYzpfhPp33 qVzQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e6si6417654ejx.444.2020.06.23.12.14.18; Tue, 23 Jun 2020 12:14:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387447AbgFWTLf (ORCPT + 99 others); Tue, 23 Jun 2020 15:11:35 -0400 Received: from mail-ej1-f41.google.com ([209.85.218.41]:45691 "EHLO mail-ej1-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733248AbgFWTLf (ORCPT ); Tue, 23 Jun 2020 15:11:35 -0400 Received: by mail-ej1-f41.google.com with SMTP id a1so8698389ejg.12; Tue, 23 Jun 2020 12:11:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=S6qzk+OKExXb2YpLZeuh1PmKG+c4jm0lpjuoeWwXFzk=; b=r9kTTD97qkKFw+q1SPYr0Wmmq3KWGMmYl1o9LsR0k5H/dgQxF1Fj/AYaVCjMl0Xfhx 952UvgI6M34fyLhH+gGlkFq+u/PMO6TWDqrp/3vpXe75uggWJLtNzU2smIEt1MrgPRsR 2LpwPNKlxLPZ1zQAgqJ/O031v3TGNxGQYDFywEUx1p4Axdgl8olSmu3knmuhr9dDI0o/ XfLw/tjQCoOrBNndsTlkMuVBK1NnExcM8UQxWElMLIF9UZH9+zIgsBYtzyWyiky7jBeU neE0PZ46Pqg0pkxQ5aM6CtRFI09dM5dNS9Mk4QCIRoNhymZ54j1MOxuf6kULC3Wwf0RY QKzQ== X-Gm-Message-State: AOAM533o31B/eNTpEmWZdnSOEhqe09EvV7r9zil3N8T3FHhrEPQ6FM96 290/5Q5+lgkg0SAxtxMMxm0= X-Received: by 2002:a17:906:4cd0:: with SMTP id q16mr13306634ejt.418.1592939492855; Tue, 23 Jun 2020 12:11:32 -0700 (PDT) Received: from kozik-lap ([194.230.155.235]) by smtp.googlemail.com with ESMTPSA id a2sm4479503ejg.76.2020.06.23.12.11.31 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 23 Jun 2020 12:11:31 -0700 (PDT) Date: Tue, 23 Jun 2020 21:11:29 +0200 From: Krzysztof Kozlowski To: Willy Wolff Cc: Chanwoo Choi , MyungJoo Ham , Kyungmin Park , Kukjin Kim , linux-pm@vger.kernel.org, "linux-samsung-soc@vger.kernel.org" , linux-arm-kernel@lists.infradead.org, "linux-kernel@vger.kernel.org" , Lukasz Luba Subject: Re: brocken devfreq simple_ondemand for Odroid XU3/4? Message-ID: <20200623191129.GA4171@kozik-lap> References: <20200623164733.qbhua7b6cg2umafj@macmini.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 23, 2020 at 09:02:38PM +0200, Krzysztof Kozlowski wrote: > On Tue, 23 Jun 2020 at 18:47, Willy Wolff wrote: > > > > Hi everybody, > > > > Is DVFS for memory bus really working on Odroid XU3/4 board? > > Using a simple microbenchmark that is doing only memory accesses, memory DVFS > > seems to not working properly: > > > > The microbenchmark is doing pointer chasing by following index in an array. > > Indices in the array are set to follow a random pattern (cutting prefetcher), > > and forcing RAM access. > > > > git clone https://github.com/wwilly/benchmark.git \ > > && cd benchmark \ > > && source env.sh \ > > && ./bench_build.sh \ > > && bash source/scripts/test_dvfs_mem.sh > > > > Python 3, cmake and sudo rights are required. > > > > Results: > > DVFS CPU with performance governor > > mem_gov = simple_ondemand at 165000000 Hz in idle, should be bumped when the > > benchmark is running. > > - on the LITTLE cluster it takes 4.74308 s to run (683.004 c per memory access), > > - on the big cluster it takes 4.76556 s to run (980.343 c per moemory access). > > > > While forcing DVFS memory bus to use performance governor, > > mem_gov = performance at 825000000 Hz in idle, > > - on the LITTLE cluster it takes 1.1451 s to run (164.894 c per memory access), > > - on the big cluster it takes 1.18448 s to run (243.664 c per memory access). > > > > The kernel used is the last 5.7.5 stable with default exynos_defconfig. > > Thanks for the report. Few thoughts: > 1. What trans_stat are saying? Except DMC driver you can also check > all other devfreq devices (e.g. wcore) - maybe the devfreq events > (nocp) are not properly assigned? > 2. Try running the measurement for ~1 minutes or longer. The counters > might have some delay (which would require probably fixing but the > point is to narrow the problem). > 3. What do you understand by "mem_gov"? Which device is it? +Cc Lukasz who was working on this. I just run memtester and more-or-less ondemand works (at least ramps up): Before: /sys/class/devfreq/10c20000.memory-controller$ cat trans_stat From : To : 165000000 206000000 275000000 413000000 543000000 633000000 728000000 825000000 time(ms) * 165000000: 0 0 0 0 0 0 0 0 1795950 206000000: 1 0 0 0 0 0 0 0 4770 275000000: 0 1 0 0 0 0 0 0 15540 413000000: 0 0 1 0 0 0 0 0 20780 543000000: 0 0 0 1 0 0 0 1 10760 633000000: 0 0 0 0 2 0 0 0 10310 728000000: 0 0 0 0 0 0 0 0 0 825000000: 0 0 0 0 0 2 0 0 25920 Total transition : 9 $ sudo memtester 1G During memtester: /sys/class/devfreq/10c20000.memory-controller$ cat trans_stat From : To : 165000000 206000000 275000000 413000000 543000000 633000000 728000000 825000000 time(ms) 165000000: 0 0 0 0 0 0 0 1 1801490 206000000: 1 0 0 0 0 0 0 0 4770 275000000: 0 1 0 0 0 0 0 0 15540 413000000: 0 0 1 0 0 0 0 0 20780 543000000: 0 0 0 1 0 0 0 2 11090 633000000: 0 0 0 0 3 0 0 0 17210 728000000: 0 0 0 0 0 0 0 0 0 * 825000000: 0 0 0 0 0 3 0 0 169020 Total transition : 13 However after killing memtester it stays at 633 MHz for very long time and does not slow down. This is indeed weird... Best regards, Krzysztof