Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp5424000ybv; Tue, 11 Feb 2020 15:39:42 -0800 (PST) X-Google-Smtp-Source: APXvYqzMVluixL1pcNXZSkd/l1CJmGBtvlVq/OpjuZD+omOmPNrs7MQM+LehLg3AyGYf+OV5cM5O X-Received: by 2002:a9d:7757:: with SMTP id t23mr7474515otl.315.1581464382327; Tue, 11 Feb 2020 15:39:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581464382; cv=none; d=google.com; s=arc-20160816; b=tuybnTdAmaQ6Ifdw1yuXN9plzB1AP4KaPm9RCmfcv3ZlXQbD+Q2vY0sKyx9mdfHStd Cf90vChMtMi4bmF74/3tmqV1/q9itoLyHPDYgIfAJeh1OBZ8ZFn8B9FIRdTPvaQ+a65M LhPx45oBlJl1R0Kdgs0po+1U1FA7OQ9aCFqU9rFfGviGZRb1rmCZfLLIPGxR4nK8F+KF uUgwcxCxe2FYiDE9cScfb/e7YxXJntbLZjZ2imhebqtJ9bumxp4/yQrDCZCI+7raKRrb LAUGZrEkYDHJeggVuaBCyQ7X2HcShCmnTZeL+DF8dI/97bHNQWzNiyTh0R6XtseukLiy gSeQ== 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 :message-id:date:subject:cc:to:from; bh=i1pXAExKvU62pOE+AoC8xh7aGYWGgnspSKymtaT0Uuo=; b=1ETPrWE/tdQOHUa4aFkz2RUtmoy3OE6qISUPqdUn0O4GoHVH7xoM7radU6fZlB+Tct 4uZ1OqYJ6iRkeeN8m/A4VtZ7czVW/T6JSCWsbubbH+kkwgryG9bayC53/o2sEFKrBvxF nWhXC3hpoUSBNBOHhEg43o4cw37K0xVBn51Hv5pqA3g7n5WJxskK2QC2NkHy9vRZzgXN DnnXtsP9D469be0X22kUk09kIjIk6lbiN7aRqHeYSlpW+JOWX+Oy377zTgHboxjr3EAh 6MffDNfgu6+nS7XKWOKlQYFHoQOuvj/tnCQZ56Po8vbrN0pXbo5GTGmLkPdZh6L4vHj5 3C9Q== 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 t3si419889oig.25.2020.02.11.15.39.30; Tue, 11 Feb 2020 15:39:42 -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; 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 S1727924AbgBKXjH (ORCPT + 99 others); Tue, 11 Feb 2020 18:39:07 -0500 Received: from cloudserver094114.home.pl ([79.96.170.134]:50793 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728189AbgBKXjF (ORCPT ); Tue, 11 Feb 2020 18:39:05 -0500 Received: from 79.184.254.199.ipv4.supernova.orange.pl (79.184.254.199) (HELO kreacher.localnet) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.341) id ac3b5ede439dbdc3; Wed, 12 Feb 2020 00:39:03 +0100 From: "Rafael J. Wysocki" To: Linux PM Cc: LKML , Amit Kucheria Subject: [PATCH 00/28] PM: QoS: Get rid of unuseful code and rework CPU latency QoS interface Date: Tue, 11 Feb 2020 23:51:05 +0100 Message-ID: <1654227.8mz0SueHsU@kreacher> 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 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!