From patchwork Thu Aug 25 08:42:42 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Shi X-Patchwork-Id: 74671 Delivered-To: patch@linaro.org Received: by 10.140.29.52 with SMTP id a49csp725997qga; Thu, 25 Aug 2016 01:45:12 -0700 (PDT) X-Received: by 10.98.65.139 with SMTP id g11mr14139534pfd.140.1472114711984; Thu, 25 Aug 2016 01:45:11 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id fn9si14445582pad.209.2016.08.25.01.45.11; Thu, 25 Aug 2016 01:45:11 -0700 (PDT) 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; 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 dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933754AbcHYIou (ORCPT + 27 others); Thu, 25 Aug 2016 04:44:50 -0400 Received: from mail-pa0-f41.google.com ([209.85.220.41]:35872 "EHLO mail-pa0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933619AbcHYInk (ORCPT ); Thu, 25 Aug 2016 04:43:40 -0400 Received: by mail-pa0-f41.google.com with SMTP id di2so15072070pad.3 for ; Thu, 25 Aug 2016 01:42:58 -0700 (PDT) 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=xxL1Y6muznBh0MWFLL2Q1RZ1LqDVM/9dgZMGjPgb6Tg=; b=UVzqZcYO+Lo5ygjde79Lc7Im8Y9sEcH7nyAh9yogG4JNKzGlLelu1GawFd26yEBi0E qEmbs4cR4+0ykF/yBLkNuwDz4QLWbzUPvjmNIL3qvB2Uw7MG+7zZKIP+L/2L/QZyqkkM McMm54Js5G4eCS4kk67ht2ooUpCS6ftHBohCQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=xxL1Y6muznBh0MWFLL2Q1RZ1LqDVM/9dgZMGjPgb6Tg=; b=YgD3lG0iJYKkZKPxSl2P+BfjmqU34DymMT71Im8FI6HmW9FEJ41nJFdSyCVDc7GZNb 0lKceQOb/gnBF2KKbKLk1bEeH+tCFpeeRpf8AJA0Zs/mIzRy3vehKwSCmkLPtrSl0AAQ qJlqF2sbY2l9u1LyVoKQEFAWk5N/yaXB4kPzWCpQz2sJXkVSBkTAMgpJqs2DCUW0gpic rF4Jyih4AIGK78l3pVgpR8fQmy6pRxs8B5zDGOGc0KZl+PsqGvraWMTrYxUSdz/24oRz 7aZ3E1dguQCgG8BTKnaTC8nZycH5UKAJm83/AJJSSHsTcquqHKeyM6mkNOqTA5Si5ptJ 483A== X-Gm-Message-State: AE9vXwNMbmpzLz8gp4RMFsdZG5T6x6V+skka4iLZZKrBfBW08JPuGdgJsSZAmk7a6qv2B/ac X-Received: by 10.66.148.7 with SMTP id to7mr14120305pab.128.1472114578225; Thu, 25 Aug 2016 01:42:58 -0700 (PDT) Received: from localhost.localdomain ([139.59.249.186]) by smtp.gmail.com with ESMTPSA id h66sm19016433pfe.58.2016.08.25.01.42.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 25 Aug 2016 01:42:57 -0700 (PDT) From: Alex Shi To: linux-kernel@vger.kernel.org (open list) Cc: linux-pm@vger.kernel.org, Ulf Hansson , Daniel Lezcano , Rasmus Villemoes , Arjan van de Ven , Rik van Riel , "Rafael J. Wysocki" Subject: [PATCH 4/4] cpuidle/menu: add per cpu pm_qos_resume_latency consideration Date: Thu, 25 Aug 2016 16:42:42 +0800 Message-Id: <1472114562-2736-4-git-send-email-alex.shi@linaro.org> X-Mailer: git-send-email 2.8.1.101.g72d917a In-Reply-To: <1472114562-2736-1-git-send-email-alex.shi@linaro.org> References: <1472114562-2736-1-git-send-email-alex.shi@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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. 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: Alex Shi 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 diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c index bb58e2a..e354880 100644 --- a/drivers/cpuidle/governors/menu.c +++ b/drivers/cpuidle/governors/menu.c @@ -12,6 +12,7 @@ #include #include +#include #include #include #include @@ -281,17 +282,23 @@ again: 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;