* [PATCH v2 0/3] per cpu resume latency @ 2017-01-12 13:27 Alex Shi 2017-01-12 13:27 ` [PATCH 1/3] cpuidle/menu: stop seeking deeper idle if current state is too deep Alex Shi ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Alex Shi @ 2017-01-12 13:27 UTC (permalink / raw) To: Greg Kroah-Hartman, Daniel Lezcano, Rafael J . Wysocki, vincent.guittot, linux-pm, linux-kernel V2 changes: remove #ifdef CONFIG_CPU_IDLE_GOV_MENU for func dev_pm_qos_expose_latency_limit(), since we have CONFIG_PM. --- cpu_dma_latency is designed to keep all cpu awake from deep c-state. That is good keep system with short response latency. But sometime we don't need all cpu power especially in a more and more multi-core day. So set all cpu restless that lead to a big power waste. A better way is to keep the short cpu response latency on needed cpu, while let other unnecesscary cpus go to deep idle. That is this patchset. We just use the pm_qos_resume_latency on cpu. Giving the short cpu latency on appointed cpu via setting value on /sys/devices/system/cpu/cpuX/power/pm_qos_resume_latency_us We can set we wanted latency value according to the value of /sys/devices/system/cpu/cpuX/cpuidle/stateX/latency. to just a bit less related state's latency value. Then cpu can get to this state or higher. Here is some testing data on my dragonboard 410c, the latency of state1 is 280us. It has 4 cores. Benchmark: cyclictest -t 1 -n -i 10000 -l 1000 -q --latency=10000 without the patch: Latency (us) Min: 87 Act: 209 Avg: 205 Max: 239 With the patch and cpu0/power/pm_qos_resume_latency_us is lower than 280us, like any value between 1 to 279 benchmark result on cpu0: Latency (us) Min: 82 Act: 91 Avg: 95 Max: 110 In repeat testing, the Avg latency always drop to half of vanilla kernel value, as well as Max latency value, although sometime the Max latency is similar with vanilla kernel. Also we could use the cpu_dma_latency to get the similar short latency. But 'idlestate' show all cpu are restless. Here is the idle status compression between cpu_dma_latency and this feature: To record idlestate #./idlestat --trace -t 10 -f /tmp/mytracepmlat -p -c -w -- cyclictest -t 1 -n -i 10000 -l 1000 -q --latency=10000 To compare the idle state, the 'total' colum show cpu1~3 nearly stay in WFI state with cpu_dma_latency. but w/ my patch, they can get about 10 second sleep in 'spc' state. # ./idlestat --import -f /tmp/mytracepmlat -b /tmp/mytrace -r comparison Log is 10.055305 secs long with 7514 events Log is 10.055370 secs long with 7545 events -------------------------------------------------------------------------------- | C-state | min | max | avg | total | hits | over | under | -------------------------------------------------------------------------------- | clusterA | -------------------------------------------------------------------------------- | WFI | 2us | 12.88ms | 4.18ms | 9.76s | 2334 | 0 | 0 | | | -2us | -14.4ms | -17us | -72.5ms | -8 | 0 | 0 | -------------------------------------------------------------------------------- | cpu0 | -------------------------------------------------------------------------------- | WFI | 3us | 100.98ms | 26.81ms | 10.03s | 374 | 0 | 0 | | | -1us | -1us | -350us | +5.0ms | +5 | 0 | 0 | -------------------------------------------------------------------------------- | cpu1 | -------------------------------------------------------------------------------- | WFI | 280us | 3.96ms | 1.96ms | 19.64ms | 10 | 0 | 5 | | | +221us | -891.7ms | -9.1ms | -9.9s | -889 | 0 | 0 | | spc | 234us | 19.71ms | 9.79ms | 9.91s | 1012 | 4 | 0 | | | +167us | +17.9ms | +8.6ms | +9.9s | +1009 | +1 | 0 | -------------------------------------------------------------------------------- | cpu2 | -------------------------------------------------------------------------------- | WFI | 86us | 1.01ms | 637us | 1.91ms | 3 | 0 | 0 | | | -16us | -26.5ms | -8.8ms | -10.0s | -1057 | 0 | 0 | | spc | 930us | 47.67ms | 10.05ms | 9.92s | 987 | 2 | 0 | | | -1.4ms | +43.7ms | +6.9ms | +9.9s | +985 | +2 | 0 | -------------------------------------------------------------------------------- | cpu3 | -------------------------------------------------------------------------------- | WFI | 0us | 0us | 0us | 0us | 0 | 0 | 0 | | | | -4.0s | -152.1ms | -10.0s | -66 | 0 | 0 | | spc | 420us | 3.50s | 913.74ms | 10.05s | 11 | 3 | 0 | | | -891us | +3.5s | +911.0ms | +10.0s | +8 | +1 | 0 | -------------------------------------------------------------------------------- Thanks Alex ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH 1/3] cpuidle/menu: stop seeking deeper idle if current state is too deep 2017-01-12 13:27 [PATCH v2 0/3] per cpu resume latency Alex Shi @ 2017-01-12 13:27 ` Alex Shi 2017-01-12 13:27 ` [PATCH v2 2/3] cpu: expose pm_qos_resume_latency for each cpu Alex Shi 2017-01-12 13:27 ` [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration Alex Shi 2 siblings, 0 replies; 18+ messages in thread From: Alex Shi @ 2017-01-12 13:27 UTC (permalink / raw) To: Greg Kroah-Hartman, Daniel Lezcano, Rafael J . Wysocki, vincent.guittot, linux-pm, linux-kernel Cc: Alex Shi, Ulf Hansson, Rasmus Villemoes, Arjan van de Ven, Rik van Riel The obsolete commit 71abbbf85 want to introduce a dynamic cstates, but it was removed for long time. Just left the nonsense deeper cstate checking. Since all target_residency and exit_latency are going longer in deeper idle state, no needs to waste some cpu cycle on useless seeking. Signed-off-by: Alex Shi <alex.shi@linaro.org> Acked-by: Rik van Riel <riel@redhat.com> To: linux-kernel@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Rik van Riel <riel@redhat.com> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> --- drivers/cpuidle/governors/menu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c index d9b5b93..07e36bb 100644 --- a/drivers/cpuidle/governors/menu.c +++ b/drivers/cpuidle/governors/menu.c @@ -357,9 +357,9 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev) if (s->disabled || su->disable) continue; if (s->target_residency > data->predicted_us) - continue; + break; if (s->exit_latency > latency_req) - continue; + break; data->last_state_idx = i; } -- 2.8.1.101.g72d917a ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH v2 2/3] cpu: expose pm_qos_resume_latency for each cpu 2017-01-12 13:27 [PATCH v2 0/3] per cpu resume latency Alex Shi 2017-01-12 13:27 ` [PATCH 1/3] cpuidle/menu: stop seeking deeper idle if current state is too deep Alex Shi @ 2017-01-12 13:27 ` Alex Shi 2017-01-17 10:23 ` Daniel Lezcano 2017-01-12 13:27 ` [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration Alex Shi 2 siblings, 1 reply; 18+ messages in thread From: Alex Shi @ 2017-01-12 13:27 UTC (permalink / raw) To: Greg Kroah-Hartman, Daniel Lezcano, Rafael J . Wysocki, vincent.guittot, linux-pm, linux-kernel Cc: Alex Shi, Ulf Hansson The cpu-dma PM QoS constraint impacts all the cpus in the system. There is no way to let the user to choose a PM QoS constraint per cpu. The following patch exposes to the userspace a per cpu based sysfs file in order to let the userspace to change the value of the PM QoS latency constraint. This change is inoperative in its form and the cpuidle governors have to take into account the per cpu latency constraint in addition to the global cpu-dma latency constraint in order to operate properly. BTW The pm_qos_resume_latency usage defined in Documentation/ABI/testing/sysfs-devices-power The /sys/devices/.../power/pm_qos_resume_latency_us attribute contains the PM QoS resume latency limit for the given device, which is the maximum allowed time it can take to resume the device, after it has been suspended at run time, from a resume request to the moment the device will be ready to process I/O, in microseconds. If it is equal to 0, however, this means that the PM QoS resume latency may be arbitrary. Signed-off-by: Alex Shi <alex.shi@linaro.org> To: linux-kernel@vger.kernel.org To: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-pm@vger.kernel.org Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> --- drivers/base/cpu.c | 2 ++ 1 file changed, 2 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 <linux/of.h> #include <linux/cpufeature.h> #include <linux/tick.h> +#include <linux/pm_qos.h> #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; } -- 2.8.1.101.g72d917a ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH v2 2/3] cpu: expose pm_qos_resume_latency for each cpu 2017-01-12 13:27 ` [PATCH v2 2/3] cpu: expose pm_qos_resume_latency for each cpu Alex Shi @ 2017-01-17 10:23 ` Daniel Lezcano 2017-01-19 8:18 ` Alex Shi 0 siblings, 1 reply; 18+ messages in thread From: Daniel Lezcano @ 2017-01-17 10:23 UTC (permalink / raw) To: Alex Shi Cc: Greg Kroah-Hartman, Rafael J . Wysocki, vincent.guittot, linux-pm, linux-kernel, Ulf Hansson On Thu, Jan 12, 2017 at 09:27:03PM +0800, Alex Shi wrote: > The cpu-dma PM QoS constraint impacts all the cpus in the system. There > is no way to let the user to choose a PM QoS constraint per cpu. > > The following patch exposes to the userspace a per cpu based sysfs file > in order to let the userspace to change the value of the PM QoS latency > constraint. > > This change is inoperative in its form and the cpuidle governors have to > take into account the per cpu latency constraint in addition to the > global cpu-dma latency constraint in order to operate properly. > > BTW > The pm_qos_resume_latency usage defined in > Documentation/ABI/testing/sysfs-devices-power > The /sys/devices/.../power/pm_qos_resume_latency_us attribute > contains the PM QoS resume latency limit for the given device, > which is the maximum allowed time it can take to resume the > device, after it has been suspended at run time, from a resume > request to the moment the device will be ready to process I/O, > in microseconds. If it is equal to 0, however, this means that > the PM QoS resume latency may be arbitrary. > > Signed-off-by: Alex Shi <alex.shi@linaro.org> > To: linux-kernel@vger.kernel.org > To: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: linux-pm@vger.kernel.org > Cc: Ulf Hansson <ulf.hansson@linaro.org> > Cc: Daniel Lezcano <daniel.lezcano@linaro.org> > Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> > --- > drivers/base/cpu.c | 2 ++ > 1 file changed, 2 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 <linux/of.h> > #include <linux/cpufeature.h> > #include <linux/tick.h> > +#include <linux/pm_qos.h> > > #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); This patch should be submitted as the last patch in the latencies constraint changes patchset IMO. It is pointless to provide an interface before a feature which is still under discussion. -- <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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 2/3] cpu: expose pm_qos_resume_latency for each cpu 2017-01-17 10:23 ` Daniel Lezcano @ 2017-01-19 8:18 ` Alex Shi 0 siblings, 0 replies; 18+ messages in thread From: Alex Shi @ 2017-01-19 8:18 UTC (permalink / raw) To: Daniel Lezcano Cc: Greg Kroah-Hartman, Rafael J . Wysocki, vincent.guittot, linux-pm, linux-kernel, Ulf Hansson On 01/17/2017 06:23 PM, Daniel Lezcano wrote: >> > >> > @@ -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); > This patch should be submitted as the last patch in the latencies constraint > changes patchset IMO. It is pointless to provide an interface before a > feature which is still under discussion. Thanks for comments! will fold it into next patch! ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration 2017-01-12 13:27 [PATCH v2 0/3] per cpu resume latency Alex Shi 2017-01-12 13:27 ` [PATCH 1/3] cpuidle/menu: stop seeking deeper idle if current state is too deep Alex Shi 2017-01-12 13:27 ` [PATCH v2 2/3] cpu: expose pm_qos_resume_latency for each cpu Alex Shi @ 2017-01-12 13:27 ` Alex Shi 2017-01-12 20:03 ` Rik van Riel 2017-01-17 9:38 ` Daniel Lezcano 2 siblings, 2 replies; 18+ messages in thread From: Alex Shi @ 2017-01-12 13:27 UTC (permalink / raw) To: Greg Kroah-Hartman, Daniel Lezcano, Rafael J . Wysocki, vincent.guittot, linux-pm, linux-kernel Cc: Alex Shi, Ulf Hansson, Rasmus Villemoes, Arjan van de Ven, Rik van Riel 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 <alex.shi@linaro.org> To: linux-kernel@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Rik van Riel <riel@redhat.com> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> --- 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 <linux/tick.h> #include <linux/sched.h> #include <linux/math64.h> +#include <linux/cpu.h> /* * 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; -- 2.8.1.101.g72d917a ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration 2017-01-12 13:27 ` [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration Alex Shi @ 2017-01-12 20:03 ` Rik van Riel 2017-01-16 1:11 ` Alex Shi 2017-01-17 9:38 ` Daniel Lezcano 1 sibling, 1 reply; 18+ messages in thread From: Rik van Riel @ 2017-01-12 20:03 UTC (permalink / raw) To: Alex Shi, Greg Kroah-Hartman, Daniel Lezcano, Rafael J . Wysocki, vincent.guittot, linux-pm, linux-kernel Cc: Ulf Hansson, Rasmus Villemoes, Arjan van de Ven [-- Attachment #1: Type: text/plain, Size: 1374 bytes --] On Thu, 2017-01-12 at 21:27 +0800, Alex Shi wrote: > 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 <alex.shi@linaro.org> > To: linux-kernel@vger.kernel.org > Cc: linux-pm@vger.kernel.org > Cc: Ulf Hansson <ulf.hansson@linaro.org> > Cc: Daniel Lezcano <daniel.lezcano@linaro.org> > Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> > Cc: Arjan van de Ven <arjan@linux.intel.com> > Cc: Rik van Riel <riel@redhat.com> > Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> > Acked-by: Rik van Riel <riel@redhat.com> -- All rights reversed [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration 2017-01-12 20:03 ` Rik van Riel @ 2017-01-16 1:11 ` Alex Shi 0 siblings, 0 replies; 18+ messages in thread From: Alex Shi @ 2017-01-16 1:11 UTC (permalink / raw) To: Rik van Riel, Greg Kroah-Hartman, Daniel Lezcano, Rafael J . Wysocki, vincent.guittot, linux-pm, linux-kernel Cc: Ulf Hansson, Rasmus Villemoes, Arjan van de Ven Thanks a lot, Rik! Anyone like to give more comments or pick it up? Regards Alex On 01/13/2017 04:03 AM, Rik van Riel wrote: > Acked-by: Rik van Riel <riel@redhat.com> ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration 2017-01-12 13:27 ` [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration Alex Shi 2017-01-12 20:03 ` Rik van Riel @ 2017-01-17 9:38 ` Daniel Lezcano 2017-01-19 9:25 ` Alex Shi 1 sibling, 1 reply; 18+ messages in thread From: Daniel Lezcano @ 2017-01-17 9:38 UTC (permalink / raw) To: Alex Shi Cc: Greg Kroah-Hartman, Rafael J . Wysocki, vincent.guittot, linux-pm, linux-kernel, Ulf Hansson, Rasmus Villemoes, Arjan van de Ven, Rik van Riel On Thu, Jan 12, 2017 at 09:27:04PM +0800, Alex Shi wrote: > 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 <alex.shi@linaro.org> > To: linux-kernel@vger.kernel.org > Cc: linux-pm@vger.kernel.org > Cc: Ulf Hansson <ulf.hansson@linaro.org> > Cc: Daniel Lezcano <daniel.lezcano@linaro.org> > Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> > Cc: Arjan van de Ven <arjan@linux.intel.com> > Cc: Rik van Riel <riel@redhat.com> > Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> > --- > 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 <linux/tick.h> > #include <linux/sched.h> > #include <linux/math64.h> > +#include <linux/cpu.h> > > /* > * 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; > + Calling dev_pm_qos_read_value() after checking latency_req is different from zero would make more sense. If a zero latency is expected, no need to add an overhead as we will return zero in all the cases. if (unlikely(latency_req == 0)) return 0; device = get_cpu_device(dev->cpu); resume_latency = dev_pm_qos_read_value(device); if (resume_latency) latency_req = min(latency_req, resume_latency); 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 ? For example, a zero PM_QOS_CPU_DMA_LATENCY latency should prevent to enter the select's idle routine. > /* Special case when user has set very strict latency requirement */ > if (unlikely(latency_req == 0)) > return 0; > -- > 2.8.1.101.g72d917a > -- <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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration 2017-01-17 9:38 ` Daniel Lezcano @ 2017-01-19 9:25 ` Alex Shi 2017-01-19 10:21 ` Daniel Lezcano 0 siblings, 1 reply; 18+ messages in thread From: Alex Shi @ 2017-01-19 9:25 UTC (permalink / raw) To: Daniel Lezcano Cc: Greg Kroah-Hartman, Rafael J . Wysocki, vincent.guittot, linux-pm, linux-kernel, Ulf Hansson, Rasmus Villemoes, Arjan van de Ven, Rik van Riel > 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 <alex.shi@linaro.org> 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 <alex.shi@linaro.org> Acked-by: Rik van Riel <riel@redhat.com> To: linux-kernel@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Rik van Riel <riel@redhat.com> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> --- 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 <linux/of.h> #include <linux/cpufeature.h> #include <linux/tick.h> +#include <linux/pm_qos.h> #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 <linux/tick.h> #include <linux/sched.h> #include <linux/math64.h> +#include <linux/cpu.h> /* * 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()); -- 2.8.1.101.g72d917a > > For example, a zero PM_QOS_CPU_DMA_LATENCY latency should prevent to enter the > select's idle routine. That's a good idea. I will give a draft change to review! :) ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration 2017-01-19 9:25 ` Alex Shi @ 2017-01-19 10:21 ` Daniel Lezcano 2017-01-19 21:43 ` Rafael J. Wysocki 0 siblings, 1 reply; 18+ messages in thread From: Daniel Lezcano @ 2017-01-19 10:21 UTC (permalink / raw) To: Alex Shi Cc: Greg Kroah-Hartman, Rafael J . Wysocki, vincent.guittot, linux-pm, linux-kernel, Ulf Hansson, Rasmus Villemoes, Arjan van de Ven, Rik van Riel On Thu, Jan 19, 2017 at 05:25:37PM +0800, Alex Shi wrote: > > > 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. Hi Alex, I think you missed the point. What I am proposing is to change the current approach by disabling all the states after a specific latency. We add a specific internal function: static int cpuidle_set_latency(struct cpuidle_driver *drv, struct cpuidle_device *dev, int latency) { int i, idx; for (i = 0, idx = 0; i < drv->state_count; i++) { struct cpuidle_state *s = &drv->states[i]; if (s->latency > latency) break; idx = i; } dev->state_count = idx; return 0; } This function is called from the notifier callback: static int cpuidle_latency_notify(struct notifier_block *b, unsigned long l, void *v) { - wake_up_all_idle_cpus(); + struct cpuidle_device *dev; + struct cpuidle_driver *drv; + + cpuidle_pause_and_lock(); + for_each_possible_cpu(cpu) { + dev = &per_cpu(cpuidle_dev, cpu); + drv = = cpuidle_get_cpu_driver(dev); + cpuidle_set_latency(drv, dev, l) + } + cpuidle_resume_and_unlock(); + return NOTIFY_OK; } ----------------------------------------------------------------------------- The menu governor becomes: diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c index bba3c2af..87e58e3 100644 --- a/drivers/cpuidle/governors/menu.c +++ b/drivers/cpuidle/governors/menu.c @@ -352,7 +352,7 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev) * Find the idle state with the lowest power while satisfying * our constraints. */ - for (i = data->last_state_idx + 1; i < drv->state_count; i++) { + for (i = data->last_state_idx + 1; i < dev->state_count; i++) { struct cpuidle_state *s = &drv->states[i]; struct cpuidle_state_usage *su = &dev->states_usage[i]; ... with a cleanup around latency_req. ----------------------------------------------------------------------------- And the cpuidle_device structure is changed to: diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h index b923c32..2fc966cb 100644 --- a/include/linux/cpuidle.h +++ b/include/linux/cpuidle.h @@ -88,6 +88,7 @@ struct cpuidle_device { cpumask_t coupled_cpus; struct cpuidle_coupled *coupled; #endif + int state_count; }; DECLARE_PER_CPU(struct cpuidle_device *, cpuidle_devices); At init time, the drv->state_count and all cpu's dev->state_count are the same. Well, that is the rough idea: instead of reading the latency when entering idle, let's disable/enable the idle states when we set a new latency. I did not check how that fits with the per cpu latency, but I think it will be cleaner to change the approach rather than spreading latencies dances around. ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration 2017-01-19 10:21 ` Daniel Lezcano @ 2017-01-19 21:43 ` Rafael J. Wysocki 2017-01-20 8:35 ` Alex Shi 2017-01-20 10:54 ` Daniel Lezcano 0 siblings, 2 replies; 18+ messages in thread From: Rafael J. Wysocki @ 2017-01-19 21:43 UTC (permalink / raw) To: Daniel Lezcano Cc: Alex Shi, Greg Kroah-Hartman, Rafael J . Wysocki, Vincent Guittot, Linux PM, Linux Kernel Mailing List, Ulf Hansson, Rasmus Villemoes, Arjan van de Ven, Rik van Riel On Thu, Jan 19, 2017 at 11:21 AM, Daniel Lezcano <daniel.lezcano@linaro.org> wrote: > On Thu, Jan 19, 2017 at 05:25:37PM +0800, Alex Shi wrote: >> >> > 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. > > Hi Alex, > > I think you missed the point. > > What I am proposing is to change the current approach by disabling all the > states after a specific latency. > > We add a specific internal function: > > static int cpuidle_set_latency(struct cpuidle_driver *drv, > struct cpuidle_device *dev, > int latency) > { > int i, idx; > > for (i = 0, idx = 0; i < drv->state_count; i++) { > > struct cpuidle_state *s = &drv->states[i]; > > if (s->latency > latency) > break; > > idx = i; > } > > dev->state_count = idx; > > return 0; > } > > This function is called from the notifier callback: > > static int cpuidle_latency_notify(struct notifier_block *b, > unsigned long l, void *v) > { > - wake_up_all_idle_cpus(); > + struct cpuidle_device *dev; > + struct cpuidle_driver *drv; > + > + cpuidle_pause_and_lock(); > + for_each_possible_cpu(cpu) { > + dev = &per_cpu(cpuidle_dev, cpu); > + drv = = cpuidle_get_cpu_driver(dev); > + cpuidle_set_latency(drv, dev, l) > + } > + cpuidle_resume_and_unlock(); > + > return NOTIFY_OK; > } The above may be problematic if the constraints change relatively often. It is global and it will affect all of the CPUs in the system every time and now think about systems with hundreds of them. Thanks, Rafael ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration 2017-01-19 21:43 ` Rafael J. Wysocki @ 2017-01-20 8:35 ` Alex Shi 2017-01-20 10:54 ` Daniel Lezcano 1 sibling, 0 replies; 18+ messages in thread From: Alex Shi @ 2017-01-20 8:35 UTC (permalink / raw) To: Rafael J. Wysocki, Daniel Lezcano Cc: Greg Kroah-Hartman, Rafael J . Wysocki, Vincent Guittot, Linux PM, Linux Kernel Mailing List, Ulf Hansson, Rasmus Villemoes, Arjan van de Ven, Rik van Riel On 01/20/2017 05:43 AM, Rafael J. Wysocki wrote: > The above may be problematic if the constraints change relatively > often. It is global and it will affect all of the CPUs in the system > every time and now think about systems with hundreds of them. Yes, the disadvantage is waking up all idle cpus when value changed. As to the multi core concern, maybe a per cpu notifier way is better? But that's another story of pm_qos... So Rafael, any comments for this patch version? Regards Alex ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration 2017-01-19 21:43 ` Rafael J. Wysocki 2017-01-20 8:35 ` Alex Shi @ 2017-01-20 10:54 ` Daniel Lezcano 2017-01-22 1:31 ` Alex Shi 1 sibling, 1 reply; 18+ messages in thread From: Daniel Lezcano @ 2017-01-20 10:54 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Alex Shi, Greg Kroah-Hartman, Rafael J . Wysocki, Vincent Guittot, Linux PM, Linux Kernel Mailing List, Ulf Hansson, Rasmus Villemoes, Arjan van de Ven, Rik van Riel On Thu, Jan 19, 2017 at 10:43:23PM +0100, Rafael J. Wysocki wrote: [ ... ] > > This function is called from the notifier callback: > > > > static int cpuidle_latency_notify(struct notifier_block *b, > > unsigned long l, void *v) > > { > > - wake_up_all_idle_cpus(); > > + struct cpuidle_device *dev; > > + struct cpuidle_driver *drv; > > + > > + cpuidle_pause_and_lock(); > > + for_each_possible_cpu(cpu) { > > + dev = &per_cpu(cpuidle_dev, cpu); > > + drv = = cpuidle_get_cpu_driver(dev); > > + cpuidle_set_latency(drv, dev, l) > > + } > > + cpuidle_resume_and_unlock(); > > + > > return NOTIFY_OK; > > } > > The above may be problematic if the constraints change relatively > often. It is global and it will affect all of the CPUs in the system > every time and now think about systems with hundreds of them. 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. But if you think the patchset is fine, it is ok, we can improve things afterwards. -- Daniel -- <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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration 2017-01-20 10:54 ` Daniel Lezcano @ 2017-01-22 1:31 ` Alex Shi 2017-01-23 12:50 ` Daniel Lezcano 0 siblings, 1 reply; 18+ messages in thread From: Alex Shi @ 2017-01-22 1:31 UTC (permalink / raw) To: Daniel Lezcano, Rafael J. Wysocki Cc: Greg Kroah-Hartman, Rafael J . Wysocki, Vincent Guittot, Linux PM, Linux Kernel Mailing List, Ulf Hansson, Rasmus Villemoes, Arjan van de Ven, Rik van Riel > 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. > > But if you think the patchset is fine, it is ok, we can improve things afterwards. > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration 2017-01-22 1:31 ` Alex Shi @ 2017-01-23 12:50 ` Daniel Lezcano 2017-01-23 14:58 ` Alex Shi 0 siblings, 1 reply; 18+ messages in thread From: Daniel Lezcano @ 2017-01-23 12:50 UTC (permalink / raw) To: Alex Shi Cc: Rafael J. Wysocki, Greg Kroah-Hartman, Rafael J . Wysocki, Vincent Guittot, Linux PM, Linux Kernel Mailing List, Ulf Hansson, Rasmus Villemoes, Arjan van de Ven, Rik van Riel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration 2017-01-23 12:50 ` Daniel Lezcano @ 2017-01-23 14:58 ` Alex Shi 0 siblings, 0 replies; 18+ messages in thread From: Alex Shi @ 2017-01-23 14:58 UTC (permalink / raw) To: Daniel Lezcano Cc: Rafael J. Wysocki, Greg Kroah-Hartman, Rafael J . Wysocki, Vincent Guittot, Linux PM, Linux Kernel Mailing List, Ulf Hansson, Rasmus Villemoes, Arjan van de Ven, Rik van Riel On 01/23/2017 08:50 PM, Daniel Lezcano wrote: > 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. Just simple change the cpu state may make it looks unnatural. :) > > 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. > Yes, before idle, it did consider lots of parts, included pm qos for long time... :) ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <1483630187-29622-1-git-send-email-alex.shi@linaro.org>]
* [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration [not found] <1483630187-29622-1-git-send-email-alex.shi@linaro.org> @ 2017-01-05 15:29 ` Alex Shi 0 siblings, 0 replies; 18+ messages in thread From: Alex Shi @ 2017-01-05 15:29 UTC (permalink / raw) To: Daniel Lezcano, Rafael J . Wysocki, vincent.guittot, open list Cc: linux-pm, Ulf Hansson, Rasmus Villemoes, Arjan van de Ven, Rik van Riel 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 <alex.shi@linaro.org> To: linux-kernel@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Rik van Riel <riel@redhat.com> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> --- 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 <linux/tick.h> #include <linux/sched.h> #include <linux/math64.h> +#include <linux/cpu.h> /* * 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; -- 2.8.1.101.g72d917a ^ permalink raw reply related [flat|nested] 18+ messages in thread
end of thread, other threads:[~2017-01-23 14:58 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-01-12 13:27 [PATCH v2 0/3] per cpu resume latency Alex Shi 2017-01-12 13:27 ` [PATCH 1/3] cpuidle/menu: stop seeking deeper idle if current state is too deep Alex Shi 2017-01-12 13:27 ` [PATCH v2 2/3] cpu: expose pm_qos_resume_latency for each cpu Alex Shi 2017-01-17 10:23 ` Daniel Lezcano 2017-01-19 8:18 ` Alex Shi 2017-01-12 13:27 ` [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration Alex Shi 2017-01-12 20:03 ` Rik van Riel 2017-01-16 1:11 ` Alex Shi 2017-01-17 9:38 ` Daniel Lezcano 2017-01-19 9:25 ` Alex Shi 2017-01-19 10:21 ` Daniel Lezcano 2017-01-19 21:43 ` Rafael J. Wysocki 2017-01-20 8:35 ` Alex Shi 2017-01-20 10:54 ` Daniel Lezcano 2017-01-22 1:31 ` Alex Shi 2017-01-23 12:50 ` Daniel Lezcano 2017-01-23 14:58 ` Alex Shi [not found] <1483630187-29622-1-git-send-email-alex.shi@linaro.org> 2017-01-05 15:29 ` Alex Shi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).