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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 7F63AC433DF for ; Wed, 24 Jun 2020 08:16:41 +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 4CFE32082F for ; Wed, 24 Jun 2020 08:16:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="qb94B5EO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4CFE32082F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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=sU18BwJXjZAjegeYv/a1qOYOfYwFEjrC6/IQAfAXJvI=; b=qb94B5EOemb0sJcWS1/UiulZ/ TNrFC+er3FN5hitivIfWFx8t9pCU5JC9YDQZ1U+27CiEFvt8eCABC1I+dS4MY4FzuHuBthiibWTDR 3DedBrI56/9v5bAO/+R4Cmu6BvGujJk+cGybwbGFVe2hWwGbWJ/yoOxGSYUepNCZouAHNNLhE6Hjy L1vT3L/kRqfPl7dYl8wpPAFe4lJylIhXP/QFPuhuWTENpz/v+zj5g8NurrnLpXQ6aYg1LTsFdkvtn nhY33q7i7NHEoCexisQPkfAyZMHFTW0DJ9xKKYRlYH+IafOlWCOTFNBH2TNkxesyP+wdMexmYJSHt AquOoU0hg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jo0YP-00048X-1y; Wed, 24 Jun 2020 08:14:45 +0000 Received: from mail-ej1-f42.google.com ([209.85.218.42]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jo0YM-000486-Md for linux-arm-kernel@lists.infradead.org; Wed, 24 Jun 2020 08:14:43 +0000 Received: by mail-ej1-f42.google.com with SMTP id a1so1510684ejg.12 for ; Wed, 24 Jun 2020 01:14:42 -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; bh=Ibh7qwsVmOM0eKJK6oTaNo8+HhtSr5AxAKMdLvNoMHg=; b=M6PCFjhMr16hv0fEjWt0/C07Tai1fXOiV5ZEkNtoAjy6oi5mjGrmILhQRT/s5ZXR8q c+thF0VTtUHkeknEojmyahlBYwKPlDDd12cDCOZ3kaUv/u1JL98W+2ys6U87hJu7tecX U3ybkUMKe50P2YWfszECobyqNzP8zaSNMibKLzqNgC1uyD9ICTUb248PYT1u7qUi73N3 PtSBFZ8IPaWw0fhOxofoaQq34+93hr21NdHgVBIHz5XZDEyRXV5675/8fTmEo4QjI/vo DOAF6lM32mvf81R/tYzlOt0LxTpuj3rkeGh/OBWsgiwe17icO+GSqcQ0ah3TWM0tqWd2 K6ag== X-Gm-Message-State: AOAM532mhws84M35d8O3+aiAxsSgGa5VVw+LMhTrNnY3iKhxwC8NhMZ0 lm50cQd403fej5+TD8oqbcY= X-Google-Smtp-Source: ABdhPJwTeuyZfApU34NyzWK0HGsXM4sXOeoUnfsKIw0gNosZtxMfWcYqWxrIgZNdijsZjlpl7dJwjQ== X-Received: by 2002:a17:907:11db:: with SMTP id va27mr11152068ejb.175.1592986481334; Wed, 24 Jun 2020 01:14:41 -0700 (PDT) Received: from pi3 ([194.230.155.235]) by smtp.googlemail.com with ESMTPSA id f16sm3512754ejr.0.2020.06.24.01.14.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jun 2020 01:14:40 -0700 (PDT) Date: Wed, 24 Jun 2020 10:14:38 +0200 From: Krzysztof Kozlowski To: Willy Wolff Subject: Re: brocken devfreq simple_ondemand for Odroid XU3/4? Message-ID: <20200624081438.GA20603@pi3> References: <20200623164733.qbhua7b6cg2umafj@macmini.local> <20200623191129.GA4171@kozik-lap> <20200624080117.fzgowkpgyhs6tbzx@macmini.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200624080117.fzgowkpgyhs6tbzx@macmini.local> 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 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... > > 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. Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel