Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1693129imm; Fri, 7 Sep 2018 04:46:07 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYqrl5OlH9QFUfVSW22D5Yy5xhdceQJ+lu07gzP9sfE95oFlWwX6va/zKqeDF8FEWWUG8h8 X-Received: by 2002:a63:3207:: with SMTP id y7-v6mr7836200pgy.101.1536320767560; Fri, 07 Sep 2018 04:46:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536320767; cv=none; d=google.com; s=arc-20160816; b=rYbF8LGs2WlXsy2DtlTHouDbKfqwGbP3ni9if7kAcFcbGaAvyCRxhbK4OSKGZiLWId NLIrpKBHokBcvDHO7itVwSSN6rVWiGbl3IFfWJzJPiB2nR6f39zhjIu+nKYT7HSHRUpO rjmovVL8kjZEMWlYI393cLLD+mugX4zTfOW9GfVTvzzO1c6bCR4/jQAgXCbt7AuttiAm nA3YBAcz5w3+NsvIyXA+VZg54gFSCLFO43u5/H+He2RewvUXB5ugRx2tVRfMRjUdlleQ mqeO0b8jQ58agUeaJUeumA/uqCO9t/j7JUPGcEj7eHMLjc3i1Ckqnp5Xf5AiF9T9HMy5 px7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=be4VuZxfcHOzgeUBZay75DXzIImMyt3JrlvOhj1NBSA=; b=l6l0D2pAC1POLpLfraUGfQ7c3ozqTLm7lBCEuRt2Kfd/RHwQbFdx7NDi9qWyDYFGbc gaOZhtAVuIQMpTdle0oT1nejlAt3zwhdMytKDiIOY2qKA54ddMPEQCj8zbwd1FUsdho/ ThDbd/WXtT+dVv80+n3TY7OoBRxDif5uAb97NF3VP56TzVnpivJ3oOpGZdQ1P+qGtskd ybCEU6tzvrzwSPybcGuQvXo9uHj+w5fUXAB4jM5qtHoASTCnypFSWPMzxqKB+KlrPQRI 3kuunoHwjqDPGD/dGaa956PriFg3q6X3vsrfbj+LfCSbssSyjZ3cKj0LmOb+lM2zH8aI pfpw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p7-v6si7680706plo.159.2018.09.07.04.45.52; Fri, 07 Sep 2018 04:46:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727829AbeIGNec (ORCPT + 99 others); Fri, 7 Sep 2018 09:34:32 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:44497 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726354AbeIGNec (ORCPT ); Fri, 7 Sep 2018 09:34:32 -0400 Received: from 79.184.254.186.ipv4.supernova.orange.pl (79.184.254.186) (HELO aspire.rjw.lan) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.123) id 13b05f37a05d7823; Fri, 7 Sep 2018 10:54:34 +0200 From: "Rafael J. Wysocki" To: Quentin Perret Cc: "Rafael J. Wysocki" , Peter Zijlstra , Linux Kernel Mailing List , Linux PM , Greg Kroah-Hartman , Ingo Molnar , Dietmar Eggemann , Morten Rasmussen , Chris Redpath , Patrick Bellasi , Valentin Schneider , Vincent Guittot , Thara Gopinath , Viresh Kumar , Todd Kjos , Joel Fernandes , Steve Muckle , adharmap@codeaurora.org, Saravana Kannan , Pavan Kondeti , Juri Lelli , Eduardo Valentin , Srinivas Pandruvada , currojerez@riseup.net, Javi Merino Subject: Re: [PATCH v6 13/14] sched/topology: Make Energy Aware Scheduling depend on schedutil Date: Fri, 07 Sep 2018 10:52:01 +0200 Message-ID: <1545744.fI5ZvP8FO0@aspire.rjw.lan> In-Reply-To: <20180906143842.xlxcg5notwdaflww@queper01-lin> References: <20180820094420.26590-1-quentin.perret@arm.com> <20180906143842.xlxcg5notwdaflww@queper01-lin> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday, September 6, 2018 4:38:44 PM CEST Quentin Perret wrote: > Hi Rafael, > > On Thursday 06 Sep 2018 at 11:18:55 (+0200), Rafael J. Wysocki wrote: > > I'm not a particular fan of notifiers to be honest and you don't need > > to add an extra chain just in order to be able to register a callback > > from a single user. > > Right. I agree there are alternatives to using notifiers. I used them > because they're existing infrastructure, and because they let me do what > I want without too much troubles, which are two important points. > > > That can be achieved with a single callback > > pointer too, but also you could just call a function exported by the > > scheduler directly from where in the cpufreq code it needs to be > > called. > > Are you thinking about something comparable to what is done in > cpufreq_add_update_util_hook() (kernel/sched/cpufreq.c) for example ? > That would probably have the same drawback as my current implementation, > that is that the scheduler is notified of _all_ governor changes, not > only changes to/from sugov although this is the only thing we care about > for EAS. Well, why don't you implement it as something like "if the governor changes from sugov to something else (or the other way around), call this function from the scheduler"?