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=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 717A3C433E6 for ; Mon, 31 Aug 2020 11:28:13 +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 3E23120866 for ; Mon, 31 Aug 2020 11:28:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="pGnOnAS/"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="VMIbLDRM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3E23120866 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.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=3XLBc5BAIp7q3EJ2GcKI0WdBAe996bgEWc0B0MisAm4=; b=pGnOnAS/ARM0pl3DbcnaWiZfy URxJb2ixB9E0kyn8S+h+P8a1DYvquffCG66WypXNdKmt/DS/SQpcnTMUjyPt2IDb3TY5ZTFzI5wUY dKi7FcZyinzVIfLSuVqfvHBsNSmPuUm2+yv+wNihz4e7AsLt/gL/HK8iSNRLzMp46BkxDr6Lw/2wS 3sCRQq9ht34/XjXs8+xDLLSXs+Roo5NnmG+rfk8ZT4cAECFf0P9Q9sjGKQdxx0aVhC7B6YW2HQKt3 m2RNMUZcPg0nQFRawMQiDGnzQ6kPZmwXo0noarGvMVlLAEylKjy5yOfQwvwOFg2GTmdJbdsXBSCR+ TIgQ0TJEg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kChxW-00073m-F6; Mon, 31 Aug 2020 11:26:46 +0000 Received: from mail-pl1-x644.google.com ([2607:f8b0:4864:20::644]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kChxT-00072n-68 for linux-arm-kernel@lists.infradead.org; Mon, 31 Aug 2020 11:26:44 +0000 Received: by mail-pl1-x644.google.com with SMTP id x18so1658688pll.6 for ; Mon, 31 Aug 2020 04:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=tH82aWUMA2UBnyH/sX2Mzmczxh4jcROvZV+v6BjFVRo=; b=VMIbLDRMLVktTIUf5zOOIdeqrwLw/V7tJr4rRKsS1JoGBJ4suScF0zyi0gT9tVpLrC 0lbZBiw/vQDNteulBImtfq+TUOpnBVGJJMUe2LVFOt/Iuo1GUg67zn6rE2hqO1ORDqyr 3EQUaprmf2kbt/cbgoqmqyE8C1aev6T+LMoAEDt5WWW/OXkazfVvq5D/n3CanLDTsDCX 4hPMsJeJcQ6Mvnv7ZPUUJ9TAaApOTyW6vLz6pmpX109HfW33joz+K619BG9tXjGJlt1m TWULz0V7MTagWxrZynTRiXPxujWKXMxLwnH9q0In6SNZFrk2xoBqukRM8t5/2KhNTloH a8pw== 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=tH82aWUMA2UBnyH/sX2Mzmczxh4jcROvZV+v6BjFVRo=; b=BLMhk9OvMGM0RF/Knd3kt3HFytn5i3ln67MVNWAJDzYaqr7TEb1Eu/bJ6G4Ut38L1D CqZ+s3A0xmbg4pWRhTBt0HPpyVFdFhOv4QDV5Jed0K7rZNCbKnbWHtGgPBv7a7ITftjm kW4Z+29Y8zfKdRVmJEYkdlZyZ6k24+aFAukg5zgT2/ahL3upJQICXwAwmHYfNNx7u0TP C9YmsOJDVabVS8EuZzOF1tpG7R8miJTtoRCpoasNP+SBWVv7IeRtM9W0K1vig7bJ7KC0 6FoYFUfgV4wIGIYAgMHaFBI9w+o8wv8VrPqQIvSoEm751h3gUHwJpoAaKH9Cb/4+r9GF 3eDg== X-Gm-Message-State: AOAM532+CYymvW8kGL7nxr8Y7cFqHJRwnHAKcsZ1izmjr8TaA2ZdxiUl KSoYDDgk8irXvwcIhvtgBOGWuQ== X-Google-Smtp-Source: ABdhPJw7Qs9sAfIfxfyEUjotME5wfjebiejj1Z5GBugIjslzE7U6vI8f7h5B/OqApj9KB4CR3Arysg== X-Received: by 2002:a17:902:bd06:: with SMTP id p6mr714908pls.255.1598873200817; Mon, 31 Aug 2020 04:26:40 -0700 (PDT) Received: from localhost ([122.167.135.199]) by smtp.gmail.com with ESMTPSA id v20sm7018867pju.14.2020.08.31.04.26.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Aug 2020 04:26:39 -0700 (PDT) Date: Mon, 31 Aug 2020 16:56:38 +0530 From: Viresh Kumar To: Ionela Voinescu Subject: Re: [RFC 0/3] cpufreq: cppc: Add support for frequency invariance Message-ID: <20200831112638.v6vyljefggptij2v@vireshk-i7> References: <20200709124349.GA15342@arm.com> <20200710030032.3yq3lqqybhy5m744@vireshk-i7> <20200825095629.GA15469@arm.com> <20200827075149.ixunmyi3m6ygtehu@vireshk-i7> <20200827112740.GA9923@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200827112740.GA9923@arm.com> User-Agent: NeoMutt/20180716-391-311a52 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200831_072643_313018_CB6708BF X-CRM114-Status: GOOD ( 32.56 ) 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: Juri Lelli , Vincent Guittot , "Rafael J. Wysocki" , Peter Zijlstra , Catalin Marinas , "open list:THERMAL" , Sudeep Holla , "Rafael J. Wysocki" , linux-kernel , Steven Rostedt , Ben Segall , Ingo Molnar , Mel Gorman , Greg Kroah-Hartman , Peter Puhov , Will Deacon , Dietmar Eggemann , LAK 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 27-08-20, 12:27, Ionela Voinescu wrote: > I don't see it as anyone registering for freq invariance, rather the > freq invariance framework chooses its source of information (AMU, CPPC, > cpufreq). Yeah, either way is fine for me. > > i.e. if CPPC registers for it first then there is no need to check > > AMUs further (as CPPC will be using AMUs anyway), else we will > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Not necessarily. Even if AMUs are present, they are only used for CPPC's > delivered and reference performance counters if the ACPI _CPC entry > specifies FFH as method: > > ResourceTemplate(){Register(FFixedHW, 0x40, 0, 1, 0x4)}, > ResourceTemplate(){Register(FFixedHW, 0x40, 0, 0, 0x4)}, Right. > While I understand your point (accessing AMUs through CPPC's read > functions to implement invariance) I don't think it's worth tying the > two together. > > I see the two functionalities as independent: > - frequency invariance with whichever source of information is valid > (AMUs, cpufreq, etc) is separate from > - CPPC's delivered and reference performance counters, which currently > are used in cpufreq's .get() function. > > Therefore, taking each of the scenarios one by one: > - All CPUs support AMUs: the freq invariance initialisation code will > find AMUs valid and it will use them to set the scale factor; > completely independently, if the FFH method is specified for CPPC's > delivered and reference performance counters, it will also use > AMUs, even if, let's say, invariance is disabled. > > - None of the CPUs support AMUs, but the _CPC entry specifies some > platform specific counters for delivered and reference performance. > With the current mainline code neither cpufreq or counter based > invariance is supported, but the CPPC counters can be used in the > cppc_cpufreq driver for the .get() function. > > But with the above new functionality we can detect that AMUs are not > supported and expose the CPPC counters to replace them in > implementing invariance. > > - Mixed scenarios are also supported if we play our cards right and > implement the above per-cpu. > > > I'm thinking that having some well defined invariance sources might work > well: it will simplify the init function (go through all registered > sources and choose (per-cpu) the one that's valid) and allow for > otherwise generic invariance support. Something like: > > enum freq_inv_source {INV_CPUFREQ, INV_AMU_COUNTERS, INV_CPPC_COUNTERS}; > > struct freq_inv_source { > enum freq_inv_source source; > bool (*valid)(int cpu); > u64 (*read_corecnt)(int cpu); > u64 (*read_constcnt)(int cpu); > u64 (*max_rate)(int cpu); > u64 (*ref_rate)(int cpu); > } > > I am in the middle of unifying AMU counter and cpufreq invariance through > something like this, so if you like the idea and you don't think I'm > stepping too much on your toes with this, I can consider the usecase in > my (what should be) generic support. So in the end this might end up > being just a matter of adding a new invariance source (CPPC counters). Okay, if you have already started working on that, no issues from my side. I can just get the relevant stuff from CPPC added once you provide that layer.. > My only worry is that while I know how a cpufreq source behaves and how > AMU counters behave, I'm not entirely sure what to expect from CPPC Neither do I :) > counters: if they are always appropriate for updates on the tick (not > blocking), The update stuff may sleep here and so I had to do stuff in the irq-work handler in my patch. > if they both stop during idle, if there is save/restore > functionality before/after idle, etc. This I will check. -- viresh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel