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 X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5C599C433E0 for ; Wed, 24 Jun 2020 08:54:14 +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 29B7C207DD for ; Wed, 24 Jun 2020 08:54:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="3IXAUr4a"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="nWxfbOrH" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 29B7C207DD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.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:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=jYidz6NnRd0KsNKUIyspLLZrqkxg+5l1xj5W9zGKm2U=; b=3IXAUr4azZnO+y3bM90yEi7rS q6GThO9tiIysiFAF1I8IHi9s72SPz/p/GmD45EJ+wz68fSg98FmIranUWgHU+UhI6t9len6Tm4p1R Mngx7rdrODGwhFF546Xyxg3WW4sW9toCt7rZ1rKqdo3mfdG+ah25Lc1GDhEy9kfohu97jHRwVWnWY BAr1rKQQlIw0YQIMqJWpX1kLwPekHohx7MtuQ5umXh7udrwaz3dzbkaMSAC1GXmSq++hgp+doSgNo A5BSLOpKQj/5BXgJUTszFQVJ70A6wG7pA3ypNGGWkt6gctBn5p8eYK62LjdLTNcqnz2Y+qxITG2Rb ktX05vkuA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jo18q-0005kN-V9; Wed, 24 Jun 2020 08:52:25 +0000 Received: from mail-wm1-x329.google.com ([2a00:1450:4864:20::329]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jo18m-0005jd-Gz for linux-arm-kernel@lists.infradead.org; Wed, 24 Jun 2020 08:52:21 +0000 Received: by mail-wm1-x329.google.com with SMTP id 17so1732061wmo.1 for ; Wed, 24 Jun 2020 01:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=lVApUt3i/7AFtwyD3Ki0a35tHO53vnjzikpdpWE5FJs=; b=nWxfbOrH2lbT0UWHSbjppQTiIjOfKj5zMlQq5Aj3dFFYMGWrUFtYGxKEQpua8lGeG7 BYPJLI9nLyJZnF+VMvul1Ya9nnO2OoP/E2XxIEpbuVltTlU/2HNK+fTd8aSCIhm1WUUp pqLlGJCyzTWO+8AzohbesMgB0/NepympE2oK7EtXXQvbbvqDN2lxSmmpB+WJ0OX1a2sX YUBayu9Russ/U2lCKcSAWD9YsC0s4KbOSXDT56uWf+Ib0qDAM84FkEAYLjIXlp7gP42d 16MIFwwdCOMOFRxGnFaXRs9/rtrTlpi8FlkSdnCz77QGPLLq4RbraWBQPmXu7SA7nKTR TRgw== 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; bh=lVApUt3i/7AFtwyD3Ki0a35tHO53vnjzikpdpWE5FJs=; b=Dpv8qKZbVBncSPO4jwhCm71MeiC5A2Ow0DakGZ1RbVwBIUWT0uLMloXljLeIcx3+sW j6ZAToCmQSoyKVtNeAamR/E0aEYJfcwpQ0Ay535ooUOYv1wosjGNiALTPwCPisaT72OB MPQ9cBZ6sqfERdMnfwYfXAi8TK3JYGWGzMR9zWLLn0rSyVqSj1FEbCw52xkEcwct139E Mica+tuwJN2R3EODMKn5QYG83Lr9pEnTyaITq5BWQGmstF3EadNHIWcrlGaDmwfcNPt+ 8nGG84I74kYnaUVqudIAcvxMagzBIYGBwj/PHW8FpjjHMrD/h41YOa3G4skVXO4mHC9B MR4Q== X-Gm-Message-State: AOAM5311T3h+jxm0IMQOwHHHxaoJyAeRcBwakegDTDE85Q6j+aM27EDq 0WGqyfbtj8MK0T6EN0UgIh4= X-Google-Smtp-Source: ABdhPJxEoDCK2NSYlVqZ8jHDnIBfhX/cA9jnzCKLxs1yjbdQAquYvO37dsRjlB2gsrPuj1Ijj4bjoQ== X-Received: by 2002:a1c:6308:: with SMTP id x8mr1289926wmb.92.1592988739418; Wed, 24 Jun 2020 01:52:19 -0700 (PDT) Received: from macmini.local (181.4.199.77.rev.sfr.net. [77.199.4.181]) by smtp.gmail.com with ESMTPSA id c20sm22140185wrb.65.2020.06.24.01.52.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jun 2020 01:52:18 -0700 (PDT) Date: Wed, 24 Jun 2020 10:52:17 +0200 From: Willy Wolff To: Krzysztof Kozlowski Subject: Re: brocken devfreq simple_ondemand for Odroid XU3/4? Message-ID: <20200624085217.5km2iexitfgclsev@macmini.local> References: <20200623164733.qbhua7b6cg2umafj@macmini.local> <20200623191129.GA4171@kozik-lap> <20200624080117.fzgowkpgyhs6tbzx@macmini.local> <20200624081438.GA20603@pi3> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200624081438.GA20603@pi3> X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "linux-samsung-soc@vger.kernel.org" , linux-pm@vger.kernel.org, "linux-kernel@vger.kernel.org" , Chanwoo Choi , Kyungmin Park , MyungJoo Ham , Kukjin Kim , Lukasz Luba , linux-arm-kernel@lists.infradead.org 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 2020-06-24-10-14-38, Krzysztof Kozlowski wrote: > On Wed, Jun 24, 2020 at 10:01:17AM +0200, Willy Wolff wrote: > > Hi Krzysztof, > > Thanks to look at it. > > > > mem_gov is /sys/class/devfreq/10c20000.memory-controller/governor > > > > Here some numbers after increasing the running time: > > > > Running using simple_ondemand: > > Before: > > From : To > > : 165000000 206000000 275000000 413000000 543000000 633000000 728000000 825000000 time(ms) > > * 165000000: 0 0 0 0 0 0 0 4 4528600 > > 206000000: 5 0 0 0 0 0 0 0 57780 > > 275000000: 0 5 0 0 0 0 0 0 50060 > > 413000000: 0 0 5 0 0 0 0 0 46240 > > 543000000: 0 0 0 5 0 0 0 0 48970 > > 633000000: 0 0 0 0 5 0 0 0 47330 > > 728000000: 0 0 0 0 0 0 0 0 0 > > 825000000: 0 0 0 0 0 5 0 0 331300 > > Total transition : 34 > > > > > > After: > > From : To > > : 165000000 206000000 275000000 413000000 543000000 633000000 728000000 825000000 time(ms) > > * 165000000: 0 0 0 0 0 0 0 4 5098890 > > 206000000: 5 0 0 0 0 0 0 0 57780 > > 275000000: 0 5 0 0 0 0 0 0 50060 > > 413000000: 0 0 5 0 0 0 0 0 46240 > > 543000000: 0 0 0 5 0 0 0 0 48970 > > 633000000: 0 0 0 0 5 0 0 0 47330 > > 728000000: 0 0 0 0 0 0 0 0 0 > > 825000000: 0 0 0 0 0 5 0 0 331300 > > Total transition : 34 > > > > With a running time of: > > LITTLE => 283.699 s (680.877 c per mem access) > > big => 284.47 s (975.327 c per mem access) > > I see there were no transitions during your memory test. > > > > > And when I set to the performance governor: > > Before: > > From : To > > : 165000000 206000000 275000000 413000000 543000000 633000000 728000000 825000000 time(ms) > > 165000000: 0 0 0 0 0 0 0 5 5099040 > > 206000000: 5 0 0 0 0 0 0 0 57780 > > 275000000: 0 5 0 0 0 0 0 0 50060 > > 413000000: 0 0 5 0 0 0 0 0 46240 > > 543000000: 0 0 0 5 0 0 0 0 48970 > > 633000000: 0 0 0 0 5 0 0 0 47330 > > 728000000: 0 0 0 0 0 0 0 0 0 > > * 825000000: 0 0 0 0 0 5 0 0 331350 > > Total transition : 35 > > > > After: > > From : To > > : 165000000 206000000 275000000 413000000 543000000 633000000 728000000 825000000 time(ms) > > 165000000: 0 0 0 0 0 0 0 5 5099040 > > 206000000: 5 0 0 0 0 0 0 0 57780 > > 275000000: 0 5 0 0 0 0 0 0 50060 > > 413000000: 0 0 5 0 0 0 0 0 46240 > > 543000000: 0 0 0 5 0 0 0 0 48970 > > 633000000: 0 0 0 0 5 0 0 0 47330 > > 728000000: 0 0 0 0 0 0 0 0 0 > > * 825000000: 0 0 0 0 0 5 0 0 472980 > > Total transition : 35 > > > > With a running time of: > > LITTLE: 68.8428 s (165.223 c per mem access) > > big: 71.3268 s (244.549 c per mem access) > > > > > > I see some transition, but not occuring during the benchmark. > > I haven't dive into the code, but maybe it is the heuristic behind that is not > > well defined? If you know how it's working that would be helpfull before I dive > > in it. > > Sorry, don't know that much. It seems it counts time between overflow of > DMC perf events and based on this bumps up the frequency. > > Maybe your test does not fit well in current formula? Maybe the formula > has some drawbacks... OK, I will read the code then. > > > > > I run your test as well, and indeed, it seems to work for large bunch of memory, > > and there is some delay before making a transition (seems to be around 10s). > > When you kill memtester, it reduces the freq stepwisely every ~10s. > > > > Note that the timing shown above account for the critical path, and the code is > > looping on reading only, there is no write in the critical path. > > Maybe memtester is doing writes and devfreq heuristic uses only write info? > > > You mentioned that you want to cut the prefetcher to have direct access > to RAM. But prefetcher also accesses the RAM. He does not get the > contents from the air. Although this is unrelated to the problem > because your pattern should kick ondemand as well. Yes obvisouly. I was just describing a bit the microbenchmark and the memory pattern access. I was suggesting that a random pattern will break the effectiveness of the prefetcher, and as such we have a worst case situation on the memory bus. > > Best regards, > Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel