From patchwork Thu Jan 12 13:27:04 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Shi X-Patchwork-Id: 91151 Delivered-To: patch@linaro.org Received: by 10.182.3.34 with SMTP id 2csp1914263obz; Thu, 12 Jan 2017 05:27:35 -0800 (PST) X-Received: by 10.98.7.11 with SMTP id b11mr16607624pfd.154.1484227655229; Thu, 12 Jan 2017 05:27:35 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v68si9294564pfb.19.2017.01.12.05.27.35; Thu, 12 Jan 2017 05:27:35 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-pm-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751504AbdALN1a (ORCPT + 13 others); Thu, 12 Jan 2017 08:27:30 -0500 Received: from mail-pf0-f169.google.com ([209.85.192.169]:35097 "EHLO mail-pf0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750796AbdALN12 (ORCPT ); Thu, 12 Jan 2017 08:27:28 -0500 Received: by mail-pf0-f169.google.com with SMTP id f144so13565445pfa.2 for ; Thu, 12 Jan 2017 05:27:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=LHtvrQ3Jk9ojoDyBaeNlQs/VdTbZ4DuxKKcgeaj1Ayk=; b=DZWiCaVyCJWQuCJVeywZGW0gYrRMUmm12A31afhgbA+PAGhLC/+cUD+y7BHXV1KJ/J /6MPBimNFVds3Ge6DRNqmfZglJb6CKDSwNzETxqEAN49ZkQ8r9yw7V0JX0bO6zn4Xn5A Nd1QXyWGOSzuXJ4EtksHsU8UTXzJ4HDQ0Xq0s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=LHtvrQ3Jk9ojoDyBaeNlQs/VdTbZ4DuxKKcgeaj1Ayk=; b=Kix9NnBxVR8fAq053Y4Sw8G10dQewUo7KeqjMnj2NLQ54MAQmCOHMSbSdjUK8xodnA 564IlsufFPkdY49Zmjd/2x8kjGrqvg70R/DUFHkHJXRgnVfT9PxEtWG5mjSj6OvCQuIE BWrnwWaP18aF0PRRCpBvIi95/LDSlAgtSRHQmFb0uI/DY6D1aU1dJyqelQUC/HJtNSFt Fb5OJzP7CEjQ86IbPVB0uOyUlBFO4y8jcfEJQLLzGEgJv639YOVNylctRCncwpc8b9oI DjorUSS/+K2dl5P2Nh9nxaXWrXMz8U6JDf+ifP7ts75yhOwTNMpqaSfHebommf+XtTzj NrCQ== X-Gm-Message-State: AIkVDXIDL4H2t+XoaUH6a9MyD4acF0vaOJNzEkRKkWM7sFYkEtNX8m3m7079XsCeAuMmo7+x X-Received: by 10.98.99.197 with SMTP id x188mr16443166pfb.179.1484227648168; Thu, 12 Jan 2017 05:27:28 -0800 (PST) Received: from localhost.localdomain ([85.203.36.61]) by smtp.gmail.com with ESMTPSA id h17sm21849939pfh.62.2017.01.12.05.27.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 12 Jan 2017 05:27:27 -0800 (PST) From: Alex Shi To: Greg Kroah-Hartman , Daniel Lezcano , "Rafael J . Wysocki" , vincent.guittot@linaro.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Alex Shi , Ulf Hansson , Rasmus Villemoes , Arjan van de Ven , Rik van Riel Subject: [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration Date: Thu, 12 Jan 2017 21:27:04 +0800 Message-Id: <1484227624-6740-4-git-send-email-alex.shi@linaro.org> X-Mailer: git-send-email 2.8.1.101.g72d917a In-Reply-To: <1484227624-6740-1-git-send-email-alex.shi@linaro.org> References: <1484227624-6740-1-git-send-email-alex.shi@linaro.org> Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org Kernel or user may have special requirement on cpu response time, like if a interrupt is pinned to a cpu, we don't want the cpu goes too deep sleep. This patch can prevent this thing happen by consider per cpu resume_latency setting in cpu sleep state selection in menu governor. The pm_qos_resume_latency ask device to give reponse in this time. That's similar with cpu cstates' entry_latency + exit_latency. But since most of cpu cstate either has no entry_latency or add it into exit_latency So, we just can restrict this time requirement as states exit_latency. We can set a wanted latency value according to the value of /sys/devices/system/cpu/cpuX/cpuidle/stateX/latency. to just a bit less than related state's latency value. Then cpu can get to this state or higher. Signed-off-by: Alex Shi To: linux-kernel@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: Ulf Hansson Cc: Daniel Lezcano Cc: Rasmus Villemoes Cc: Arjan van de Ven Cc: Rik van Riel Cc: "Rafael J. Wysocki" --- drivers/cpuidle/governors/menu.c | 7 +++++++ 1 file changed, 7 insertions(+) -- 2.8.1.101.g72d917a -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Acked-by: Rik van Riel diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c index 07e36bb..8d6d25c 100644 --- a/drivers/cpuidle/governors/menu.c +++ b/drivers/cpuidle/governors/menu.c @@ -19,6 +19,7 @@ #include #include #include +#include /* * Please note when changing the tuning values: @@ -280,17 +281,23 @@ static unsigned int get_typical_interval(struct menu_device *data) static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev) { struct menu_device *data = this_cpu_ptr(&menu_devices); + struct device *device = get_cpu_device(dev->cpu); int latency_req = pm_qos_request(PM_QOS_CPU_DMA_LATENCY); int i; unsigned int interactivity_req; unsigned int expected_interval; unsigned long nr_iowaiters, cpu_load; + int resume_latency = dev_pm_qos_read_value(device); if (data->needs_update) { menu_update(drv, dev); data->needs_update = 0; } + /* resume_latency is 0 means no restriction */ + if (resume_latency && resume_latency < latency_req) + latency_req = resume_latency; + /* Special case when user has set very strict latency requirement */ if (unlikely(latency_req == 0)) return 0;