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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E2E08C433F5 for ; Fri, 15 Oct 2021 11:32:45 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id AED5160F8F for ; Fri, 15 Oct 2021 11:32:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org AED5160F8F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org 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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=iBnaSCatrttyFa+oKYBtt2BGD/kXgCaGMdRsOM4lliw=; b=YfxVATO/aq2RPP XLT3MQ1TBSQhegSIfEz+YQ4H7wadEjX4AtIS9n3sNc7QjewqKVSJvdFpwWXOxsS89EyPcYyhYekWD k27ndM5TWZTfDXcACCduakvEk79CYC0YJHJnhgZPSeubb2rb+e2wWhwabwoM8r5Dak5Hu2Vy9ZFPC 5gbYbItQqopVvDsNLMfGM95kMtZeW4rn709eqXO7f61+E4kwQfuGh4fujpHDGiUgarZ+isK9WBrDX CcaMVBNQQli8yaE5AqDWXBh4PdeLQ8aGxrIiQw+/b9oMEjD/P2s4lNPdq9LWDgliq1Qwzwz0I5ZGd CQT4QuJFFuFJjy9bYzwQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mbLQF-006jsO-42; Fri, 15 Oct 2021 11:30:48 +0000 Received: from mail-oi1-x22a.google.com ([2607:f8b0:4864:20::22a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mbLMn-006ijH-V5 for linux-arm-kernel@lists.infradead.org; Fri, 15 Oct 2021 11:27:15 +0000 Received: by mail-oi1-x22a.google.com with SMTP id e63so12579965oif.8 for ; Fri, 15 Oct 2021 04:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NKgeFjMzQGbOlv7b4giRKfd3xluRkC6Y3aCMzdKTmcI=; b=Wm4Wd6dvvDFnTkE00hxoA1bUki0lOHa+WoFWUIXZWiyl6BYiN/VJMfw+VnMnOCFaCL jQ/04aPgGreSwDm51jxnPJc9pkqywXE26egdgnLAAok719vghfDASfmYTOjn+J9+fwG+ q/10lDtvDgAT1UYJHz5rI7tM4bgXHiMlTFU0bfwd97rrUQBuH+ZcmSEP+7HO6CUo/zZr CYvsbAtjc89xss/CKzqeHdvLDimYn1hwLBeYUoQqfujZ+roY4R1sCnIjQGg7W3W/Tmsf Xo/iQrJTbgRFodmMVP5Xapec+3WlJ78UAXbtc9fa6D6bWDahM/6PJbdWmF+2ol5JsZXE T1fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NKgeFjMzQGbOlv7b4giRKfd3xluRkC6Y3aCMzdKTmcI=; b=gw67Tx2U89PQ8tZlmVXvEA1q4c/kwJXMPy2qJV/UfJpr4Mc8ztZgUqtWUd3w7rlaw1 l3rvysYml5WgtEQA37Rvh9YSMPu73U5Rd2XOjczjmVc3YTxkBld+bBfQwdRuStHsobyP C2dbGEAT7SXc4xwahOf7W9dtBA8dJoQmnfcinLtIv8+xD9kJp/HDHlrT7lr3/Ha3JaL+ zeGHZssS3G0hXOHTLI9yDETX2+ER4OCLMWTj/mry0Wc6qVQ3yR0RNAF3lefCNzqFCYK2 Tbbxh0nlRgTi5sg4JH9GL6lPT79ypmUKPZNVkOIplXr5ctSDBHlFi0QSvqNtt4Cagb78 lciw== X-Gm-Message-State: AOAM530+PfujfkHAaH1TGK/Vqr2sOKnjVn9GDhAItwn0PmXvJgvKDpBB k6ncMEl2YI7xs6iYQYOcfpi3RocUKj4m79iiJPSNnQ== X-Google-Smtp-Source: ABdhPJyDcpqGbwskrQSivF3Hrk9czLe3jAaUJI090sO0PPQ/+jfBKyc4oV3D64eX1CbrHycowOE0cMxWzV6ZAtM7o8E= X-Received: by 2002:a05:6808:2218:: with SMTP id bd24mr513771oib.94.1634297231969; Fri, 15 Oct 2021 04:27:11 -0700 (PDT) MIME-Version: 1.0 References: <20211011165707.138157-1-marcan@marcan.st> <20211011165707.138157-5-marcan@marcan.st> <20211012032144.2ltlpat7orrsyr6k@vireshk-i7> <20211012055143.xmkbvhbnolspgjin@vireshk-i7> In-Reply-To: From: Ulf Hansson Date: Fri, 15 Oct 2021 13:26:35 +0200 Message-ID: Subject: Re: [RFC PATCH 4/9] opp: core: Don't warn if required OPP device does not exist To: Hector Martin Cc: Viresh Kumar , Sibi Sankar , Saravana Kannan , Linux ARM , Alyssa Rosenzweig , Sven Peter , Marc Zyngier , Mark Kettenis , Michael Turquette , Stephen Boyd , Rob Herring , Krzysztof Kozlowski , Viresh Kumar , Nishanth Menon , Catalin Marinas , "Rafael J. Wysocki" , Kevin Hilman , linux-clk , DTML , Linux PM , Linux Kernel Mailing List X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211015_042714_118618_355B0A95 X-CRM114-Status: GOOD ( 28.90 ) 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 Thu, 14 Oct 2021 at 19:02, Hector Martin wrote: > > On 14/10/2021 21.55, Ulf Hansson wrote: > > On Thu, 14 Oct 2021 at 13:43, Hector Martin wrote: > >> I was poking around and noticed the OPP core can already integrate with > >> interconnect requirements, so perhaps the memory controller can be an > >> interconnect provider, and the CPU nodes can directly reference it as a > >> consumer? This seems like a more accurate model of what the hardware > >> does, and I think I saw some devices doing this already. > > > > Yeah, that could work too. And, yes, I agree, it may be a better > > description of the HW. > > > >> > >> (only problem is I have no idea of the actual bandwidth numbers involved > >> here... I'll have to run some benchmarks to make sure this isn't just > >> completely dummy data) > >> > > So... I tried getting bandwidth numbers and failed. It seems these > registers don't actually affect peak performance in any measurable way. > I'm also getting almost the same GeekBench scores on macOS with and > without this mechanism enabled, although there is one subtest that seems > to show a measurable difference. > > My current guess is this is something more subtle (latencies? idle > timers and such?) than a performance state. If that is the case, do you > have any ideas as to the best way to model it in Linux? Should we even > bother if it mostly has a minimal performance gain for typical workloads? For latency constraints, we have dev_pm_qos. This will make the genpd governor, to prevent deeper idle states for the device and its corresponding PM domain (genpd). But that doesn't sound like a good fit here. If you are right, it rather sounds like there is some kind of quiescence mode of the memory controller that can be prevented. But I have no clue, of course. :-) > > I'll try to do some latency tests, see if I can make sense of what it's > actually doing. > Kind regards Uffe _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel