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 B63FEC433EF for ; Thu, 14 Oct 2021 17:03:49 +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 7AF0861151 for ; Thu, 14 Oct 2021 17:03:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7AF0861151 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=marcan.st 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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ig90tkbWja8lZCoahvRNY0brnp6R+QHD18Df4FRlO/4=; b=Y7FBa1g0IVqh+K9AZkM+C5oxj3 hJZ3CBK7hOykFtDSmgKUHuDxM09xeEpwm3AME69pprGz/f69z0z8FHrrEQ1q/YmgSexErtgDylv27 VltXqkZxroVn7wJ5OcjFk/PISFakfo8aneX6RHushyAfon0GnKmYpHR5bnPZGav7/TtQT42xk7WR2 xj5JJ0o9PWf+LHAcsV9FoP80o/b7MJgM6mSVesTrwRnYfHQ8LLD+/2vPkWTsqdq6T2/ie21ne56AL IVDJjP/5adMe4lDuyY/2dHu2IHD8jrezOwAa4sp6WKoPVJsrXWAVpArK/sNZWUGW+de5tnyKImUIm LkKu8oSQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mb47m-003wEY-Cs; Thu, 14 Oct 2021 17:02:34 +0000 Received: from marcansoft.com ([2a01:298:fe:f::2] helo=mail.marcansoft.com) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mb47i-003wDh-KH for linux-arm-kernel@lists.infradead.org; Thu, 14 Oct 2021 17:02:32 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: marcan@marcan.st) by mail.marcansoft.com (Postfix) with ESMTPSA id 1BFD73FA5E; Thu, 14 Oct 2021 17:02:21 +0000 (UTC) Subject: Re: [RFC PATCH 4/9] opp: core: Don't warn if required OPP device does not exist To: Ulf Hansson 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 References: <20211011165707.138157-1-marcan@marcan.st> <20211011165707.138157-5-marcan@marcan.st> <20211012032144.2ltlpat7orrsyr6k@vireshk-i7> <20211012055143.xmkbvhbnolspgjin@vireshk-i7> From: Hector Martin Message-ID: Date: Fri, 15 Oct 2021 02:02:19 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Language: es-ES X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211014_100230_848226_15819BFA X-CRM114-Status: GOOD ( 20.25 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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? I'll try to do some latency tests, see if I can make sense of what it's actually doing. -- Hector Martin (marcan@marcan.st) Public Key: https://mrcn.st/pub _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel