From patchwork Thu Jan 19 09:25:37 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Shi X-Patchwork-Id: 9525347 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 5BE6460113 for ; Thu, 19 Jan 2017 09:34:14 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 44199277D9 for ; Thu, 19 Jan 2017 09:34:14 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 377B827C7A; Thu, 19 Jan 2017 09:34:14 +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=unavailable 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 B38B927F93 for ; Thu, 19 Jan 2017 09:34:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751778AbdASJeM (ORCPT ); Thu, 19 Jan 2017 04:34:12 -0500 Received: from mail-qt0-f170.google.com ([209.85.216.170]:33188 "EHLO mail-qt0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751742AbdASJeJ (ORCPT ); Thu, 19 Jan 2017 04:34:09 -0500 Received: by mail-qt0-f170.google.com with SMTP id v23so58413918qtb.0 for ; Thu, 19 Jan 2017 01:34:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=N40iu+14JvHbARQqilMaHDdhEAZX+SPDatGFF7yBlQw=; b=dTn1UiKturc4RXdST0uXGNNKBn2xF7d3wjQuMlcfOWjVzUpufklGoTjIImg6+h7DC3 OgTRR+XznHp47TldekwQi5IA18ZrPeQV0/XzgkpwpIPmJoaW0X14ZcFwPfvrsiywPLri BPHrOPZywLAOyPcR4cXwR8NqtnCmwzkdhkkP0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=N40iu+14JvHbARQqilMaHDdhEAZX+SPDatGFF7yBlQw=; b=LpeoPSPcQ8/P3dTt10YYDnKR0gL0ZCmEuWcbsBti6dt206DqV6zz1J7qTXBT5PKpv3 dZaLkMjIVx+/HGYxJtZExEhAhOyF9JUzR8Y5UnFeb0L8Tj55HKSKWSxxbAWi0q4WCYMz jpqISf0DJDU/Y7k9i3L/VXPAhs68TREvYW0U5g1RXQ9rKknLW7OZN7uRbJnHua9blk4E v8+76ZIc4fGOnxgJT16wT+kM0/FjYjNlx7RK80gzhc3+LhMt0FD5c0+mvGRqOw5PcTMq ZwjabdYLVZStJCW2aGNuqrITG/pnGjwOy6M49XoLUWVAIBUelKwMfy90w0FNI+e283EB DXRg== X-Gm-Message-State: AIkVDXJiucJnSKN++D0loPOsU4kWOWLLN527lK3n0N3F7GZq3LsCkwiqBRzjWN9JgLsHLrMc X-Received: by 10.55.107.71 with SMTP id g68mr6579176qkc.259.1484817945459; Thu, 19 Jan 2017 01:25:45 -0800 (PST) Received: from [10.21.10.78] ([85.203.36.40]) by smtp.googlemail.com with ESMTPSA id d15sm2582669qtg.22.2017.01.19.01.25.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jan 2017 01:25:44 -0800 (PST) Subject: Re: [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration To: Daniel Lezcano References: <1484227624-6740-1-git-send-email-alex.shi@linaro.org> <1484227624-6740-4-git-send-email-alex.shi@linaro.org> <20170117093837.GA2085@mai> Cc: Greg Kroah-Hartman , "Rafael J . Wysocki" , vincent.guittot@linaro.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Ulf Hansson , Rasmus Villemoes , Arjan van de Ven , Rik van Riel From: Alex Shi Message-ID: <01f9b016-0b7c-44ac-70e5-8cd9b8bd1500@linaro.org> Date: Thu, 19 Jan 2017 17:25:37 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20170117093837.GA2085@mai> 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 > That said, I have the feeling that is taking the wrong direction. Each time we > are entering idle, we check the latencies. Entering idle can be done thousand > of times per second. Wouldn't make sense to disable the states not fulfilling > the constraints at the moment the latencies are changed ? As the idle states > have increasing exit latencies, setting an idle state limit to disable all > states after that limit may be more efficient than checking again and again in > the idle path, no ? You'r right. save some checking is good thing to do. From 9e1cc3e02b8d954e606dd5a0f6466a8d5b3efab7 Mon Sep 17 00:00:00 2001 From: Alex Shi Date: Wed, 26 Oct 2016 15:26:22 +0800 Subject: [PATCH 2/2] cpuidle/menu: add per cpu pm_qos_resume_latency consideration 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 Acked-by: Rik van Riel 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/base/cpu.c | 2 ++ drivers/cpuidle/governors/menu.c | 10 ++++++++++ 2 files changed, 12 insertions(+) diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c index 4c28e1a..2c3b359 100644 --- a/drivers/base/cpu.c +++ b/drivers/base/cpu.c @@ -17,6 +17,7 @@ #include #include #include +#include #include "base.h" @@ -376,6 +377,7 @@ int register_cpu(struct cpu *cpu, int num) per_cpu(cpu_sys_devices, num) = &cpu->dev; register_cpu_under_node(num, cpu_to_node(num)); + dev_pm_qos_expose_latency_limit(&cpu->dev, 0); return 0; } diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c index 07e36bb..cc7d873 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,11 +281,13 @@ 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; 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; if (data->needs_update) { menu_update(drv, dev); @@ -295,6 +298,13 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev) if (unlikely(latency_req == 0)) return 0; + device = get_cpu_device(dev->cpu); + + /* resume_latency is 0 means no restriction */ + resume_latency = dev_pm_qos_read_value(device); + if (resume_latency) + latency_req = min(latency_req, resume_latency); + /* determine the expected residency time, round up */ data->next_timer_us = ktime_to_us(tick_nohz_get_sleep_length());