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=-3.8 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 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 7BBD7C4742C for ; Thu, 5 Nov 2020 14:26:37 +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 E535F206B5 for ; Thu, 5 Nov 2020 14:26:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="A/JQDErQ"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="pptPNx+r" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E535F206B5 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: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=odpgpcLgASeAEN2miMShYzS53jm5aVV+8RamWo9hpjo=; b=A/JQDErQcfjH3nVMy5U2MEW6/ ztY4XzYQQrWK5N+OHrh+ESH1Xg/SUKJIAVY+gvNQy2SG9RXATs5l+/nkT9EDhK2GzTjMfJfzGz5lT Wf7RuPTW+GoCZ+3ONHyvNrXRIGwealiZ0CneY4LuAwwXS/D1PgQkk46FEOawcCF+2jss/D+/Ll/l5 0Z/F6COFnviLzi5+sckMT5wOiDtHeMM6P+n3sSGt/1jX0I04jMG0CXfexi/KF9rn5iBCAt9tl92SK 44bDlKZqK2aYmCAc2bSj5QA6yhXljw6L4P78Ta0XZlbETkTRzxjZPIghnRkL1Unf2Y3fgnYhfk2K4 UBPB+CFKA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kagDK-0003AJ-A7; Thu, 05 Nov 2020 14:26:10 +0000 Received: from mail-lj1-x243.google.com ([2a00:1450:4864:20::243]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kagDH-00039o-1w for linux-arm-kernel@lists.infradead.org; Thu, 05 Nov 2020 14:26:08 +0000 Received: by mail-lj1-x243.google.com with SMTP id d24so1755396ljg.10 for ; Thu, 05 Nov 2020 06:26:06 -0800 (PST) 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=nQ7ga1nkChbgCNcp4Ysi78tNBZumkjAPVt4V0by2Rm8=; b=pptPNx+rPKH+x8ujYpmcYsyk+OSaKWXu77RvkAt9PkUW9Em/bfITai0EeR5btFlbga H9I7ln/IHvqioPTlV6w9QmZAdFToDVYMsCVCLxVkS8HdWZaKNUxU7DRjvJvNRztT7CnC G7aySamX2FtDLHidKTRgYHvzlr9Hmp1s+GDA33Um8IxwSlWeUc0pv1aP1BxKAPo6ox+H MlCp2OTmbeeaCfB5QfrJ3j/ST6o75MEjSUZxYHfb7CiXNN8ZfLyNHII0RFnZ3ksB9Wst sGuyuVtlmXbjQ4XAh0MbwV1ZlccZ7DTvP2EFCrpuxlaO6BXe4AQQ7DUQDk8SlphH8C5+ GeZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nQ7ga1nkChbgCNcp4Ysi78tNBZumkjAPVt4V0by2Rm8=; b=ZxZNtvGy646T3wwDS1UFnMwt4LVohsa8yucxhpAJJs7zueeyhcQ/qb6yPVKg4v0pxC AozyI9USf55JbOZ5P8NA6Q8o7ZQ+F31eVUZOeD8Z6OPamcIUrQgsohBWDfBP3b8KIZaY E2CzZyC0SUgQJjoKlmeNePcLIlBG8mW0+IMOqIROAKuMv8Bva9UFubJeJ6OIT+4Rq+pP CmZtw9z1RcadsVycOSb2K6XdaVj0qKpuxO+sGPiQjQG9KTNCL2fCPWq3MFDIDoOppPUC GeY50aCpztmwW1Atm9afiN98NM+ylC8lm1jB+BlnDgCUF4EVObMyUe3GGUWsF9piM6nH BGwA== X-Gm-Message-State: AOAM533mZGv2pIA59uheUwE4AlV3Dy/jNya01v1YHCoS05oP9p09UO5T Oo7RZdKKk46CA0O933WNHijFnXFgCnVAUB6Z5ObVdw== X-Google-Smtp-Source: ABdhPJxojzyjuq7Nj7ikSubvMrtczulnP1sYUG9Acvch7VPEunsyTvFdj2dDMWpVKYNODrC4v0vcXiLI77RWHXj2jNE= X-Received: by 2002:a2e:9583:: with SMTP id w3mr1042305ljh.25.1604586365033; Thu, 05 Nov 2020 06:26:05 -0800 (PST) MIME-Version: 1.0 References: <20201102120115.29993-1-nicola.mazzucato@arm.com> <20201103101840.yrgwmcjrnjn7n5q6@vireshk-i7> <87558fa9-a4c6-38c9-bcc5-f736c0229f56@arm.com> In-Reply-To: <87558fa9-a4c6-38c9-bcc5-f736c0229f56@arm.com> From: Vincent Guittot Date: Thu, 5 Nov 2020 15:25:53 +0100 Message-ID: Subject: Re: [PATCH v3 0/3] CPUFreq: Add support for cpu performance dependencies To: Nicola Mazzucato X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201105_092607_809742_1211E4DB X-CRM114-Status: GOOD ( 34.28 ) 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: Nishanth Menon , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , "open list:THERMAL" , Stephen Boyd , Viresh Kumar , Daniel Lezcano , "Rafael J. Wysocki" , linux-kernel , Rob Herring , Sudeep Holla , Chris Redpath , Ionela Voinescu , Morten Rasmussen , LAK , Viresh Kumar 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, 4 Nov 2020 at 19:02, Nicola Mazzucato wrote: > > Hi Viresh, thanks for looking into this. > > On 11/3/20 10:18 AM, Viresh Kumar wrote: > > On 02-11-20, 12:01, Nicola Mazzucato wrote: > >> Hi All, > >> > >> In this V3 posting I have replaced the new dt-binding with minor changes/ > >> improvements for opp (since we are now using opp tables instead). > >> The RFC still stands on how to make this info available to sw consumers. > >> > >> In the RFC, I am proposing a simple addition of a performance dependencies > >> cpumask in CPUFreq core and an example of how drivers and consumers would > >> make use of it. > >> I also propose an alternative approach, which does not require changes in > >> CPUFreq core, but - possibly - in all the consumers. > >> > >> This is to support systems where exposed cpu performance controls are more > >> fine-grained that the platform's ability to scale cpus independently. > > > > I was talking to Vincent about what you are doing here and we got a > > bit confused and so here are few questions that we had: > > > > - Based on my previous understanding, you don't want software > > coordination of frequencies (which is done by cpufreq today), but > > want the hardware to do that and so you want per-cpu cpufreq > > policies. > > Correct. And this has been done for quite some time in some platforms. > > > > > - What's the real benefit of hardware coordination ? Want to make sure > > I fully understand that. > > The hardware coordination that is coming out by having per-cpu cpufreq policies > is not new, and works just fine in most of the systems. > > The benefit of having per-cpu controls is that the firmware will take care of > the performance of the entire system. It is purely a delegation to firmware for > the performance optimizations. > > > > > - Because of hardware co-ordination of otherwise co-ordinated CPUs, > > few things break. Thermal and EAS are some of the examples and so > > you are trying to fix them here by proving them the missing > > information again. > > Correct. And for this I have proposed two ways. > > > > > - One other thing that breaks with this is freq-invariance in the > > scheduler, as the scheduler won't see the real frequencies the > > various CPUs are running at. Most of the hardware we have today > > doesn't have counters, like AMUs, not sure if all future ones based > > on SCMI will have that too, so how are they gong to be fixed ? > > > > Correct. freq-invariance without counters is trying to do its best based on the > information it has available. It definitely relies on the knowledge of the v/f > domains to work at its best so I think in the case of per-cpu it will follow the > same approach as others being affected (EAS, thermal). As frequency invariance has same problem as EAS and Thermal it would be good to see the solution as part of this proposal like EAS and Thermal > > > And if we even have to fix this (freq invariance), what's hardware > > coordination giving us that makes all this worth it ? > > I suppose this is more a generic question for all the platforms running with h/w > coordination, but for our case is that the f/w will take care of the performance > optimizations for us :) > > > > > Sorry about the long list :) > > No problem at all. Thank you for your time on this and I hope I have made bits > clearer. > > Nicola > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel