From patchwork Thu Jan 5 15:29:47 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Shi X-Patchwork-Id: 9499213 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 3CCD2606E0 for ; Thu, 5 Jan 2017 15:30:49 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 32CD32840E for ; Thu, 5 Jan 2017 15:30:49 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 26FA828416; Thu, 5 Jan 2017 15:30:49 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.3 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C7DD228416 for ; Thu, 5 Jan 2017 15:30:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S969417AbdAEPak (ORCPT ); Thu, 5 Jan 2017 10:30:40 -0500 Received: from mail-io0-f182.google.com ([209.85.223.182]:35423 "EHLO mail-io0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S970958AbdAEPa1 (ORCPT ); Thu, 5 Jan 2017 10:30:27 -0500 Received: by mail-io0-f182.google.com with SMTP id n85so247156781ioi.2 for ; Thu, 05 Jan 2017 07:30:27 -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=qqYWYxdv8M0zfY/TsQAmFYpVhzldHvWEXtWxiEU53E0=; b=HcDcyJLmGnwhZllI8h3lHymYADec9CZhG020W/dZywBbJK7t28KMrTJ8FG18mI3VgD LutFLoDr3Sc7mnctcEug/biZmXD8Hj7k7XrymvG3eSa2v6qaukhvc70NzEd568TLxrQI nmO3joCzNl47cUj/ygt8DjfHeNCF2pnOuf5iI= 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=qqYWYxdv8M0zfY/TsQAmFYpVhzldHvWEXtWxiEU53E0=; b=ltFakPjyu6WS5rkViEUX+PJMda6j2VN1wPRV4fCBbG7mOw7uPMUKo8oq/qwlJeninc evFD91OQSgkody8horJMW8UG+QX0rIc4XX28uvJmqqODQ6M+3SKwcZRjCcJH2RbPjf50 ypMn9UQP2sc1huTbKwLRObx6iFzEP53ixuZ0ROoD6UyON+Xtf8xXBNcFvNEyRS/wueSX +xr5103RZRUXAMJyK/l3JaNm8s4szsX5dwgaqjzMWdUA7ylyT0wlLCZCDzM2EzAsNuf1 dkKruE/i/XPeiu+FEgRtwDdjubPN/l19KjSyzq3Q66JCZEDoobrShj+0ArVWbrEOOC15 vCmA== X-Gm-Message-State: AIkVDXKhz8+YbZHtYVpRAiIF+25ixpSOxNDaVPjj4ECZhkEuM/WVJYFO1oL9FKLKmPJAuN3z X-Received: by 10.107.135.93 with SMTP id j90mr31872596iod.171.1483630226598; Thu, 05 Jan 2017 07:30:26 -0800 (PST) Received: from localhost.localdomain ([85.203.36.82]) by smtp.gmail.com with ESMTPSA id 130sm36051198ity.5.2017.01.05.07.30.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Jan 2017 07:30:26 -0800 (PST) From: Alex Shi To: Daniel Lezcano , "Rafael J . Wysocki" , vincent.guittot@linaro.org, linux-kernel@vger.kernel.org (open list) Cc: linux-pm@vger.kernel.org, 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, 5 Jan 2017 23:29:47 +0800 Message-Id: <1483630187-29622-4-git-send-email-alex.shi@linaro.org> X-Mailer: git-send-email 2.8.1.101.g72d917a In-Reply-To: <1483630187-29622-1-git-send-email-alex.shi@linaro.org> References: <1483630187-29622-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 X-Virus-Scanned: ClamAV using ClamSMTP 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. The 0 value of pm_qos_resume_latency is for no limitation according ABI definition. So set the value 1 could get the 0 latency if it's needed. 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(+) 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;