Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp5822330ybv; Wed, 12 Feb 2020 00:40:28 -0800 (PST) X-Google-Smtp-Source: APXvYqyBC2GE1gA1PI47BQaZ/gmwoJs9CTTabzcl8YEzJE45z3Hso7SLkbU4WfhRtO3gDaBG+k90 X-Received: by 2002:aca:4ece:: with SMTP id c197mr5548078oib.53.1581496828494; Wed, 12 Feb 2020 00:40:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581496828; cv=none; d=google.com; s=arc-20160816; b=MF2DQPh9Zy9wD6uJiacNG5G/qaoFrkBcdd8Lma/VQR6Cpf/QiXeAPktEMvXB4F7BWN DgvKn1DZogDNYt2bjlDbNyd0OML9THApFGhlpTE0ovbEIvFuflrx42lvVYay0+GAaSmD g81odwN1Ni7KIdzMcHtL+h6/S+i91e/+PWweck5lKg9aD3qviaZtHDJbQsJKaMSWRrz/ DspAG6xmLQDSECqRiStSCjYLcBn5mDixMFk5mk+3ymAc5gfcSwHjhVnkTPPSTHO078Wx 8wgRSjdpHhV4SpYaA0/prsQIaIS8RckqXFey7zs/6ujFTkW4CHzyGWC+6467XCSWEQNM 80yg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=IHqIf5M4paWRQqNMsUfuUrTYwOKU9w45APayE5qNVvs=; b=P+/G0YhIU2ih3aYewCS3Osug6FminhflfmWnAs3x0AdONdBwOU1Fvlt6zXiI0DWGnD 2wNrYoC/jvQGABWRwmSjyGNsHQWvjKRy8NV2Dm+lZKbrqK+rblEyW92IQiiNUS5GQpcN zKo5GIXXI+FZD21+4USQzTMZl6C2JPIheOPASDBeGE+4trBYvmIdvDJiPfRAVvUfQc9U 4sFfMpGGDLfwk8Sw36AwmjWvovlB7TLL+6QnPZ+i0hhuNKa1MQj2aRBhqZWZF8fjqiKF zw7I7bMz5AeM9F/9wIpMn3bFtdqm1bnpWkwf+o2KS3Iadd/gtU4LLhO+v+qbR70tHuXh PmuA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="vUVL+4E/"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n9si3134453ota.103.2020.02.12.00.40.15; Wed, 12 Feb 2020 00:40:28 -0800 (PST) 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; dkim=pass header.i=@linaro.org header.s=google header.b="vUVL+4E/"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728532AbgBLIih (ORCPT + 99 others); Wed, 12 Feb 2020 03:38:37 -0500 Received: from mail-vs1-f66.google.com ([209.85.217.66]:46768 "EHLO mail-vs1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728478AbgBLIih (ORCPT ); Wed, 12 Feb 2020 03:38:37 -0500 Received: by mail-vs1-f66.google.com with SMTP id t12so615674vso.13 for ; Wed, 12 Feb 2020 00:38:35 -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=IHqIf5M4paWRQqNMsUfuUrTYwOKU9w45APayE5qNVvs=; b=vUVL+4E/ghJvS34Gw+Yj3FC8/V75VOYPhxzpJQgUT6tMqtb9vakYs2GI0k47MFdUq3 hQ1YQcUXc0R3WTcUgNgO26qcrxwrfbqBk8S03K72PonAAM+wa+C7YAI/+/h1u75Nz7/6 bXs/K7tD0boEOfEK1j5rFSpxQ77Uht/WRcvdkmaS3Qj/Koerbc7RXmgQiNpT2BqMIviV c1aPNJQ2gzdl+kOtoNYtLEv30u82JjAHSQ6Ha2Pvzj9QtPHdRuICR1mVFVspd4LEEt2F HLSKF5IedVsH0ZCyqPErwfyRP6aU38jYRni922g7VV6DWoY0s4Hj+QxK6PLixQimyXkh AKRA== 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=IHqIf5M4paWRQqNMsUfuUrTYwOKU9w45APayE5qNVvs=; b=sy4AFsXhh0dXqxXBo6ELqsURPw49CUE0i1Ve2GkosYTlO99Z5/3DwxT6CvG9qymR0u X7Nv0BE0Aoib7PZECUkW+pNQAMCe56KgnzNLcpOwu6P33JtPGRAHKxFAiH04em9AgMXZ nBgqas1ZjkZf65VAQOvDfYpNCnbDEzWFmjNo4ZsH3XjuGeVkPvBMe1yIxs8US9MSojI3 OYOCZxVUZsjC0Odlqao3s0qUIPj+C3gt0rZCjmaQJjNu5oECmJviap1G2SlT9evrJmXm 5gc8D90BSl9MH+w0CIFq29GCsUnF8XWw8C8knYUXTNpc+fw6dAcB0vqYSJcI/2K7MuHP OUnQ== X-Gm-Message-State: APjAAAWiKP648Ef7HkNG8v42mczpx/vMGDWT94LeaDIc2DcmGtJDsV+M DR574ML2FQR/FwLUay69RVCg32nknlIDeIs+gU76MvW7 X-Received: by 2002:a67:f591:: with SMTP id i17mr605202vso.34.1581496715171; Wed, 12 Feb 2020 00:38:35 -0800 (PST) MIME-Version: 1.0 References: <1654227.8mz0SueHsU@kreacher> In-Reply-To: <1654227.8mz0SueHsU@kreacher> From: Ulf Hansson Date: Wed, 12 Feb 2020 09:37:59 +0100 Message-ID: Subject: Re: [PATCH 00/28] PM: QoS: Get rid of unuseful code and rework CPU latency QoS interface To: "Rafael J. Wysocki" Cc: Linux PM , LKML , Amit Kucheria Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 12 Feb 2020 at 00:39, Rafael J. Wysocki wrote: > > Hi All, > > This series of patches is based on the observation that after commit > c3082a674f46 ("PM: QoS: Get rid of unused flags") the only global PM QoS class > in use is PM_QOS_CPU_DMA_LATENCY, but there is still a significant amount of > code dedicated to the handling of global PM QoS classes in general. That code > takes up space and adds overhead in vain, so it is better to get rid of it. > > Moreover, with that unuseful code removed, the interface for adding QoS > requests for CPU latency becomes inelegant and confusing, so it is better to > clean it up. > > Patches [01/28-12/28] do the first part described above, which also includes > some assorted cleanups of the core PM QoS code that doesn't go away. > > Patches [13/28-25/28] rework the CPU latency QoS interface (in the classic > "define stubs, migrate users, change the API proper" manner), patches > [26-27/28] update the general comments and documentation to match the code > after the previous changes and the last one makes the CPU latency QoS depend > on CPU_IDLE (because cpuidle is the only user of its target value today). > > The majority of the patches in this series don't change the functionality of > the code at all (at least not intentionally). > > Please refer to the changelogs of individual patches for details. > > Thanks! A big thanks for cleaning this up! The PM_QOS_CPU_DMA_LATENCY and friends, has been annoying me for a long time. This certainly makes the code far better and more understandable! I have looked through the series and couldn't find any obvious mistakes, so feel free to add: Reviewed-by: Ulf Hansson Note, the review tag also means, that's fine for you to pick the mmc patch via your tree. Kind regards Uffe