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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 A02ABC47E49 for ; Wed, 23 Oct 2019 08:57:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7617921929 for ; Wed, 23 Oct 2019 08:57:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1571821075; bh=Lwvkii9O6i8TeRIS90CrQG+PaKrHNklGhiv0zd2R+dk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=cOLeow0zS1TxWDyqoXwTDa/+RWCaW7h9oafHGWGMO2UZPtRdflfUPWCbOeH5pQ2io eNtCZI7yVfXVL3dbMNosAI5HPh7VBk0k/9GiqZcwk/3KuHwlImTcQ9VRt8RQqbNsaI 8f3tenoyndVZrgjSQalMtdbgm2Flff9mwtWrFXFM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390485AbfJWI5y (ORCPT ); Wed, 23 Oct 2019 04:57:54 -0400 Received: from mail-oi1-f195.google.com ([209.85.167.195]:34333 "EHLO mail-oi1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387829AbfJWI5y (ORCPT ); Wed, 23 Oct 2019 04:57:54 -0400 Received: by mail-oi1-f195.google.com with SMTP id 83so16738849oii.1; Wed, 23 Oct 2019 01:57:52 -0700 (PDT) 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=+SgWDtx0/EohgvsL2Dr3cG8xzUVsn7JdTYAZdxeMPfg=; b=oUfJ2mjhJFMJ60ad42Y7nlf1r6nSXrvD5lljqYgL9u8G3krMTGB7+C3ia2n22l/v8K bO7b8vMvnuGbWp2O2VnqFxYZJ7fLdGZzBtMMpfsAkK9leOfVRuPTtke8+brgcdp/YfVs gZCPD0U4iXlZ0e6+UHhLiMmusBL+c7a89Fk7pOOnnPNIERdEZR53qPQvuUaNAdbiGhXu 9mIb2/CErKNHqvXCgl2Cv0S2JrXfrV5afUN8v6SQdNFZ+ywKShSsKtXSShkkBwLfskp6 yU7iOwnMTtpVwsiUswSIfUgzCpwM8e82RIZLcdq06QYo2gzBCej/DxNLNcr6FZfoKaIW SiHw== X-Gm-Message-State: APjAAAVY41Y5Onz21QCpt1vg91fwXnholWOvwApFFC5zLnqyntRq6R+a osaBjr2/7IN98Ht3wSJ31/Ix0s/gsJjUq0h8qYo= X-Google-Smtp-Source: APXvYqwhTBg9vuA1Oqj9UiGYZuKXA2wZzV8vgNARWImcMs2DbYEml/kicZIjjXGr2bCaenXjJbEL488WLAVz7xersw0= X-Received: by 2002:aca:d706:: with SMTP id o6mr6916124oig.57.1571821072330; Wed, 23 Oct 2019 01:57:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Rafael J. Wysocki" Date: Wed, 23 Oct 2019 10:57:41 +0200 Message-ID: Subject: Re: [RFT][PATCH 0/3] cpufreq / PM: QoS: Introduce frequency QoS and use it in cpufreq To: Leonard Crestez Cc: "Rafael J. Wysocki" , Viresh Kumar , Linux ACPI , Linux PM , Sudeep Holla , Dmitry Osipenko , Matthias Kaehlcke , Kyungmin Park , Chanwoo Choi , =?UTF-8?B?QXJ0dXIgxZp3aWdvxYQ=?= , Georgi Djakov , dl-linux-imx , Saravana Kannan , MyungJoo Ham Content-Type: text/plain; charset="UTF-8" Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On Wed, Oct 23, 2019 at 10:54 AM Rafael J. Wysocki wrote: > > On Wed, Oct 23, 2019 at 4:20 AM Leonard Crestez wrote: > > > > On 2019-10-23 1:48 AM, Rafael J. Wysocki wrote: > > > On Wed, Oct 23, 2019 at 12:06 AM Leonard Crestez > > > wrote: > > >> I've been working on a series which add DEV_PM_QOS support to devfreq, > > >> now at v9: > > >> > > >> Your third patch removes DEV_PM_QOS_FREQUENCY_MIN/MAX that my series > > >> depends upon. I found the email on patchwork, hopefully the in-reply-to > > >> header is OK? > > >> > > >> As far as I can tell the replacement ("frequency qos") needs constraints > > >> to be managed outside the device infrastructure and it's not obviously > > >> usable a generic mechanism for making "min_freq/max_freq" requests to a > > >> specific device. > > > > > > You can add a struct freq_constrants pointer to struct dev_pm_info and > > > use it just fine. It doesn't have to be bolted into struct > > > dev_pm_qos. > > > > I'm not sure what you mean by this? min/max_freq was already available > > in dev_pm_qos so it's not clear why it would be moved somewhere else. > > What I'm looking for is a mechanism to make min/max_freq requests on a > > per-device basis and DEV_PM_QOS_MIN_FREQUENCY already did that. > > > > Reuse is good, right? > > But they go away in patch 3 of this series as there are no users in > the tree. Sorry about that. > > > >> I've read a bit through your emails and it seems the problem is that > > >> you're dealing with dev_pm_qos on per-policy basis but each "struct > > >> cpufreq_policy" can cover multiple CPU devices. > > >> > > >> An alternative solution which follows dev_pm_qos would be to add > > >> notifiers for each CPU inside cpufreq_online and cpufreq_offline. This > > >> makes quite a bit of sense because each CPU is a separate "device" with > > >> a possibly distinct list of qos requests. > > > > > > But combining the lists of requests for all the CPUs in a policy > > > defeats the idea of automatic aggregation of requests which really is > > > what PM QoS is about. > > > > My primary interest is the "dev" part of dev_pm_qos: making pm_qos > > requests tied to a specific device. > > The list of requests needs to be associated with the user of the > effective constraint. If that is the device, it is all good. > > > > There have to be two lists of requests per policy, one for the max and > > > one for the min frequency > > > >> If cpufreq needs a group of CPUs to run at the same frequency then it > > >> should deal with this by doing dev_pm_qos_read_frequency on each CPU > > >> device and picking a frequency that attempts to satisfy all constraints. > > > > > > No, that would be combining the requests by hand. > > > > It's just a loop though. > > Yes, it is, and needs to be run on every change of an effective > constraint for any CPU even if the total effective constraint doesn't > change. And, of course, the per-policy user space limits would need > to be combined with that by hand. > > Not particularly straightforward if you asked me. > > Not to mention the fact that, say, cpu_cooling, has a per-policy list > of requests anyway. A per-policy request, not a list of them. Sorry.