[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170123125025.GB2166@mai>
Date: Mon, 23 Jan 2017 13:50:25 +0100
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: Alex Shi <alex.shi@...aro.org>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Linux PM <linux-pm@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Ulf Hansson <ulf.hansson@...aro.org>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
Arjan van de Ven <arjan@...ux.intel.com>,
Rik van Riel <riel@...hat.com>
Subject: Re: [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency
consideration
On Sun, Jan 22, 2017 at 09:31:44AM +0800, Alex Shi wrote:
>
> >Yeah, that could be problematic. The code snippet gives the general idea but it
> >could be changed by for example by a flag telling the cpus when they enter idle
> >to update their state_count. Or something like that.
>
> Yes, this idea could be helpful.
>
> But since the idle path isn't a hot path. and a few memory access won't cost
> a lot. So I doubt if the benefit could be measurable.
It won't be measurable, as well as reading the cpu device latency before
checking the latency req is zero, but it makes sense.
The idle routine is not a hot path but a very special place where the interrupt
are disabled, the rcu is not usable, tick is disabled etc ...
Perhaps it is not a problem for the moment, but it is probably worth to mention that
using API from other subsystems in the idle select path could be problematic
and perhaps it is time to think about another approach for the future.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
Powered by blists - more mailing lists