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.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 9D128C388F2 for ; Thu, 22 Oct 2020 11:07:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 19C42223BF for ; Thu, 22 Oct 2020 11:07:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="KtCmAvWU" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2896977AbgJVLHA (ORCPT ); Thu, 22 Oct 2020 07:07:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58406 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2896965AbgJVLG7 (ORCPT ); Thu, 22 Oct 2020 07:06:59 -0400 Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C1FC9C0613CF for ; Thu, 22 Oct 2020 04:06:59 -0700 (PDT) Received: by mail-pg1-x543.google.com with SMTP id s22so720061pga.9 for ; Thu, 22 Oct 2020 04:06:59 -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=5F1P3cDyZZfB+5wQAJZN/bSRRcbsJk9yH9Mp8FnRfG0=; b=KtCmAvWUglFJkVFnOpbKc+tedHFB8GWLzyy5Pf2YNN/ltIPGpeE8VV3Ezrjnf6MtIV Iw4YsvNEjCjJ/OfyB5p3R99DTyqL8uYJRhtq4+teGl6/7a0rL1YIDTb5zMHpu9uUcipF 6JdheIPbQRh2Bw6KUfUrHXrpyZaFQYVP5LvGejO9lqEsy/eRPGt0KsURP9/q+NolQXTi diBLTSbgB+kw+mgQ9Pfi6wRP7eec4Lce/cOInisWYBqnWovam16o1mQTRtwPTVxY3t03 amLoYsvpP5RAv7CpiC3bYM8aSUIQOIAjof7yIO8+Rx+9hduyEbCUSfk9rskNrfQyrgr1 OLxg== 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=5F1P3cDyZZfB+5wQAJZN/bSRRcbsJk9yH9Mp8FnRfG0=; b=j4puLmLWHcWW6NPawJ38tttPJWuzKCv9aB52PlmeRB2ZXBNo4tKcFtPLTZG4EDjyAc UOaSu1kgpq3mV33ECKr5h6AvsqWXWKIfwvZk703JktdcT7c0bwq0Uo2cRYWmh1kfjSnx MRlPFbx3eOw44csWj9RH+8n5bwF/TnGfXQjL4bN5P2JoullMG+5nwo+uHrUg0rv1sbH+ dAE0PoIFLQzrk87Ocdmobn9M4/VPegpBlBwSh6rKDiwsVILZYpB2F6wU6QIsx2AnV2Y9 5FTkQeOMaooZA2Bv6UUqQSBKk36NMfiCp9CPSFw9Pz0792r8v9x/HRr0C07gvrxZjILo bghg== X-Gm-Message-State: AOAM531vAWfDIPP30PyD95JOe+VhYLdN80PP3vjIjxPA74JKiAj/WEkG HnFSOlFPFB30vWUFMbap284/zg== X-Google-Smtp-Source: ABdhPJwe/yxHcXuREOavhKWa2LijXwU7OHCva5pj9T8tlFVE8ZZKFk9++TWqYSyj+47QdqGv+rSW8w== X-Received: by 2002:a62:7609:0:b029:152:b31e:6aed with SMTP id r9-20020a6276090000b0290152b31e6aedmr2031340pfc.10.1603364819189; Thu, 22 Oct 2020 04:06:59 -0700 (PDT) Received: from localhost ([122.181.54.133]) by smtp.gmail.com with ESMTPSA id u2sm1944980pgf.63.2020.10.22.04.06.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Oct 2020 04:06:58 -0700 (PDT) Date: Thu, 22 Oct 2020 16:36:56 +0530 From: Viresh Kumar To: Peter Zijlstra Cc: Ingo Molnar , Vincent Guittot , Zhang Rui , Daniel Lezcano , Amit Daniel Kachhap , Javi Merino , Amit Kucheria , linux-kernel@vger.kernel.org, Quentin Perret , Rafael Wysocki , linux-pm@vger.kernel.org, lukasz.luba@arm.com Subject: Re: [PATCH 2/2] thermal: cpufreq_cooling: Reuse effective_cpu_util() Message-ID: <20201022110656.gaphjv2tzhj4f5y6@vireshk-i7> References: <20200716115605.GR10769@hirez.programming.kicks-ass.net> <20201022083255.37xl3lffwk5qo6uk@vireshk-i7> <20201022090523.GV2628@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201022090523.GV2628@hirez.programming.kicks-ass.net> User-Agent: NeoMutt/20180716-391-311a52 Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On 22-10-20, 11:05, Peter Zijlstra wrote: > On Thu, Oct 22, 2020 at 02:02:55PM +0530, Viresh Kumar wrote: > > One of the issues I see with this is that schedutil may not be > > available in all configurations and it is still absolutely fine to > > using the suggested helper to get the energy numbers in such cases, so > > we shouldn't really make it scheutil dependent. > > The only constraint on schedutil is SMP I think; aside from that it > should/could always be available. > > Given the trainwreck here: > > 20201022071145.GM2628@hirez.programming.kicks-ass.net > > (you're on Cc), I'm starting to lean more and more towards making it > unconditionally available (when SMP). > > Anybody forcing it off either sets performance (in which case we don't > care about energy usage anyway) I agree. > or they select one of the old (broken) > ondemand/conservative things and I don't give a crap. The other kernel layers, for example cpufreq-cooling in question here, don't really need to bother with the governor in use and should be able to get the energy numbers anyway. So for me, the energy number that the cpufreq-cooling stuff gets should be same irrespective of the governor in use, schedutil or ondemand. Having said that, schedutil really doesn't need to install the fallback (which you suggested earlier), rather the scheduler core can do that directly with cpufreq core and schedutil can also use the same fallback mechanism maybe ? And so we can avoid the exporting of stuff that way. -- viresh