On 01/21/2015 05:16 PM, Thomas Gleixner wrote:
> On Tue, 20 Jan 2015, Preeti U Murthy wrote:
>> diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
>> index 5544990..f3907c9 100644
>> --- a/kernel/time/clockevents.c
>> +++ b/kernel/time/clockevents.c
or tick_check_broadcast_expired() returns false, without setting
the resched flag. So a cpu will be caught in cpu_idle_poll() needlessly,
thereby wasting power. Add an explicit check on cpu_idle_force_poll and
tick_check_broadcast_expired() to the exit condition of cpu_idle_poll()
to avoid this.
Signed-off-by: Preeti U
On 01/21/2015 03:26 PM, Thomas Gleixner wrote:
> On Tue, 20 Jan 2015, Preeti U Murthy wrote:
>> On 01/20/2015 04:51 PM, Thomas Gleixner wrote:
>>> On Mon, 19 Jan 2015, Preeti U Murthy wrote:
>>>> An idle cpu enters cpu_idle_poll() if it is set in the
On 01/21/2015 05:16 PM, Thomas Gleixner wrote:
On Tue, 20 Jan 2015, Preeti U Murthy wrote:
diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
index 5544990..f3907c9 100644
--- a/kernel/time/clockevents.c
+++ b/kernel/time/clockevents.c
@@ -568,6 +568,7 @@ int
On 01/21/2015 03:26 PM, Thomas Gleixner wrote:
On Tue, 20 Jan 2015, Preeti U Murthy wrote:
On 01/20/2015 04:51 PM, Thomas Gleixner wrote:
On Mon, 19 Jan 2015, Preeti U Murthy wrote:
An idle cpu enters cpu_idle_poll() if it is set in the
tick_broadcast_force_mask.
This is so that it does
or tick_check_broadcast_expired() returns false, without setting
the resched flag. So a cpu will be caught in cpu_idle_poll() needlessly,
thereby wasting power. Add an explicit check on cpu_idle_force_poll and
tick_check_broadcast_expired() to the exit condition of cpu_idle_poll()
to avoid this.
Signed-off-by: Preeti U
On 01/20/2015 11:15 AM, Michael Ellerman wrote:
> On Mon, 2015-19-01 at 11:32:51 UTC, Preeti U Murthy wrote:
>> The device tree now exposes the residency values for different idle states.
>> Read
>> these values instead of calculating residency from the latency values. The
On 01/20/2015 04:51 PM, Thomas Gleixner wrote:
> On Mon, 19 Jan 2015, Preeti U Murthy wrote:
>> An idle cpu enters cpu_idle_poll() if it is set in the
>> tick_broadcast_force_mask.
>> This is so that it does not incur the overhead of entering idle states when
>> it is
it explicitly.
It fixes the bug reported here:
http://linuxppc.10917.n7.nabble.com/offlining-cpus-breakage-td88619.html
Signed-off-by: Preeti U Murthy
---
Changes from previous versions:
1. Modification to the changelog
2. Clarified the comments
kernel/time/clockevents.c|2 +-
kernel/time/tick
it explicitly.
It fixes the bug reported here:
http://linuxppc.10917.n7.nabble.com/offlining-cpus-breakage-td88619.html
Signed-off-by: Preeti U Murthy
---
Changes from V1: https://lkml.org/lkml/2015/1/19/168
1. Modified the Changelog
kernel/time/clockevents.c|2 +-
kernel/time/tick-broadcast.c
it explicitly.
It fixes the bug reported here:
http://linuxppc.10917.n7.nabble.com/offlining-cpus-breakage-td88619.html
Signed-off-by: Preeti U Murthy pre...@linux.vnet.ibm.com
---
Changes from V1: https://lkml.org/lkml/2015/1/19/168
1. Modified the Changelog
kernel/time/clockevents.c|2
it explicitly.
It fixes the bug reported here:
http://linuxppc.10917.n7.nabble.com/offlining-cpus-breakage-td88619.html
Signed-off-by: Preeti U Murthy pre...@linux.vnet.ibm.com
---
Changes from previous versions:
1. Modification to the changelog
2. Clarified the comments
kernel/time/clockevents.c
On 01/20/2015 11:15 AM, Michael Ellerman wrote:
On Mon, 2015-19-01 at 11:32:51 UTC, Preeti U Murthy wrote:
The device tree now exposes the residency values for different idle states.
Read
these values instead of calculating residency from the latency values. The
values
exposed in the DT
On 01/20/2015 04:51 PM, Thomas Gleixner wrote:
On Mon, 19 Jan 2015, Preeti U Murthy wrote:
An idle cpu enters cpu_idle_poll() if it is set in the
tick_broadcast_force_mask.
This is so that it does not incur the overhead of entering idle states when
it is expected
to be woken up anytime
On 01/20/2015 11:39 AM, Michael Ellerman wrote:
> On Mon, 2015-19-01 at 10:26:48 UTC, Preeti U Murthy wrote:
>> Today if a cpu handling broadcasting of wakeups goes offline, it hands over
>
> It's *the* cpu handling broadcasting of wakeups right? ie. there's only ever
> one
does not expose residency
values, use default values as a fallback mechanism. While at it, clump
the common parts of device tree parsing into one chunk.
Signed-off-by: Preeti U Murthy
---
drivers/cpuidle/cpuidle-powernv.c | 39 -
1 file changed, 25 insertions
phase so that it is visible to
all cpus right after exiting stop_machine, which is when they can re-enter idle.
This ensures that handover of the broadcast duty falls in place on offline,
without
having to do it explicitly.
Signed-off-by: Preeti U Murthy
---
kernel/time/clockevents.c|2
On 01/20/2015 11:39 AM, Michael Ellerman wrote:
On Mon, 2015-19-01 at 10:26:48 UTC, Preeti U Murthy wrote:
Today if a cpu handling broadcasting of wakeups goes offline, it hands over
It's *the* cpu handling broadcasting of wakeups right? ie. there's only ever
one at a time.
Right, thanks
phase so that it is visible to
all cpus right after exiting stop_machine, which is when they can re-enter idle.
This ensures that handover of the broadcast duty falls in place on offline,
without
having to do it explicitly.
Signed-off-by: Preeti U Murthy pre...@linux.vnet.ibm.com
---
kernel/time
does not expose residency
values, use default values as a fallback mechanism. While at it, clump
the common parts of device tree parsing into one chunk.
Signed-off-by: Preeti U Murthy pre...@linux.vnet.ibm.com
---
drivers/cpuidle/cpuidle-powernv.c | 39 -
1
power. Hence exit
the idle
poll loop if the tick_broadcast_force_mask gets cleared and enter idle states.
Of course if the cpu has entered cpu_idle_poll() on being asked to poll
explicitly,
it continues to poll till it is asked to reschedule.
Signed-off-by: Preeti U Murthy
---
kernel/sched
power. Hence exit
the idle
poll loop if the tick_broadcast_force_mask gets cleared and enter idle states.
Of course if the cpu has entered cpu_idle_poll() on being asked to poll
explicitly,
it continues to poll till it is asked to reschedule.
Signed-off-by: Preeti U Murthy pre
Hi Jacob,
On 12/23/2014 08:27 AM, Jacob Pan wrote:
> On Sat, 20 Dec 2014 07:01:12 +0530
> Preeti U Murthy wrote:
>
>> On 12/20/2014 01:26 AM, Thomas Gleixner wrote:
>>> On Fri, 19 Dec 2014, Jacob Pan wrote:
>>>
>>>> On Thu, 18 Dec 2014 22:
Hi Jacob,
On 12/23/2014 08:27 AM, Jacob Pan wrote:
On Sat, 20 Dec 2014 07:01:12 +0530
Preeti U Murthy pre...@linux.vnet.ibm.com wrote:
On 12/20/2014 01:26 AM, Thomas Gleixner wrote:
On Fri, 19 Dec 2014, Jacob Pan wrote:
On Thu, 18 Dec 2014 22:12:57 +0100 (CET)
Thomas Gleixner t
operations when the cpu coming online can go out of sync
with
the idle periods. But that situation exists today as well.
Signed-off-by: Preeti U Murthy
---
Missed Ccing LKML on the previous mail.
drivers/thermal/intel_powerclamp.c | 227 ++--
include/linux/sched.h
operations when the cpu coming online can go out of sync
with
the idle periods. But that situation exists today as well.
Signed-off-by: Preeti U Murthy pre...@linux.vnet.ibm.com
---
Missed Ccing LKML on the previous mail.
drivers/thermal/intel_powerclamp.c | 227
age idle, which I am sure we can work around with
a better design such as the above. I am working on that patchset and
will post out in a day. You can take a look and let us know the pieces
we are missing.
I find that implementing the above design is not too hard.
Regards
Preeti U Murthy
--
To unsubscri
design is not too hard.
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
d they are set by an idle task.
4. When need_resched is set again, the idle task of course unsets inidle
and restarts tick. In the following scheduler tick,
pick_next_task_fair() sees that rq->need_throttle is cleared, enqueues
back the tasks and returns one of them to run.
Of course there may b
there may be several points that I have missed. But how does
the approach appear? If it looks sane enough, the cases which do not
obviously fall in place can be worked upon.
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
rupt()) {
> /*
> * Prevent raise_softirq from needlessly waking up ksoftirqd
> * here, as softirq will be serviced on return from interrupt.
> @@ -363,7 +363,7 @@ static inline void tick_irq_exit(void)
> int cpu = smp_processor_id();
will not do. It may solve
this regression,but the check is incomplete.
IMO it should simply be :
if (tick_nohz_tick_stopped() || tick_nohz_full_cpu())
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
On 12/15/2014 03:02 PM, Viresh Kumar wrote:
> On 15 December 2014 at 12:55, Preeti U Murthy
> wrote:
>> Hi Viresh,
>>
>> Let me explain why I think this is happening.
>>
>> 1. tick_nohz_irq_enter/exit() both get called *only if the cpu is idle*
>> and
On 12/15/2014 03:02 PM, Viresh Kumar wrote:
On 15 December 2014 at 12:55, Preeti U Murthy pre...@linux.vnet.ibm.com
wrote:
Hi Viresh,
Let me explain why I think this is happening.
1. tick_nohz_irq_enter/exit() both get called *only if the cpu is idle*
and receives an interrupt.
Bang
mer to force a scheduler tick to update the
jiffies. Since this happens on cpus in a package, all of them get soft
lockedup.
Hope the above explanation makes sense.
Regards
Preeti U Murthy
On 12/12/2014 05:27 PM, Viresh Kumar wrote:
> Cc'ing Thomas as well..
>
> On 12 December 2014 at 01:1
to force a scheduler tick to update the
jiffies. Since this happens on cpus in a package, all of them get soft
lockedup.
Hope the above explanation makes sense.
Regards
Preeti U Murthy
On 12/12/2014 05:27 PM, Viresh Kumar wrote:
Cc'ing Thomas as well..
On 12 December 2014 at 01:12, Fengguang Wu
On 12/11/2014 10:26 AM, Santosh Shukla wrote:
> On 11 December 2014 at 10:14, Preeti U Murthy
> wrote:
>> On 12/10/2014 06:22 PM, Viresh Kumar wrote:
>>> On 10 December 2014 at 18:03, Preeti U Murthy
>>> wrote:
>>>
>>>> Right. We get an int
On 12/11/2014 10:26 AM, Santosh Shukla wrote:
On 11 December 2014 at 10:14, Preeti U Murthy pre...@linux.vnet.ibm.com
wrote:
On 12/10/2014 06:22 PM, Viresh Kumar wrote:
On 10 December 2014 at 18:03, Preeti U Murthy pre...@linux.vnet.ibm.com
wrote:
Right. We get an interrupt when nobody
On 12/10/2014 06:22 PM, Viresh Kumar wrote:
> On 10 December 2014 at 18:03, Preeti U Murthy
> wrote:
>
>> Right. We get an interrupt when nobody had asked for it to be delivered
>> or had asked for it to be delivered and later canceled the request. It
>> is most of
robably because during hrtimer handling, we traverse all queued timers
and call their handlers, till we find timers whose expiry is in the
future. I would not be surprised if we overshoot the expiry of the
timers at the end of the list by a microsecond by the time we call their
handlers.
Regards
P
On 12/10/2014 06:22 PM, Viresh Kumar wrote:
On 10 December 2014 at 18:03, Preeti U Murthy pre...@linux.vnet.ibm.com
wrote:
Right. We get an interrupt when nobody had asked for it to be delivered
or had asked for it to be delivered and later canceled the request. It
is most often
by a microsecond by the time we call their
handlers.
Regards
Preeti U Murthy
Tested on: Ivybrdge V2, 12 core X86 server, though it occurs on ARM as well
(but not that frequent).
Regards,
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
..957a04951ef0 100644
> --- a/kernel/time/timer_list.c
> +++ b/kernel/time/timer_list.c
> @@ -229,7 +229,10 @@ print_tickdevice(struct seq_file *m, struct tick_device
> *td, int cpu)
> SEQ_printf(m, "\n");
>
> SEQ_printf(m, " set_mode: ");
> -
);
+ else
+ print_name_offset(m, dev-set_mode);
SEQ_printf(m, \n);
SEQ_printf(m, event_handler: );
Reviewed-by: Preeti U Murthy pre...@linux.vnet.ibm.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
. While at it, give a name to this mode of broadcast which was
missing all along.
Signed-off-by: Preeti U Murthy
Tested-by: Mark Rutland
---
Changes from V1: https://lkml.org/lkml/2014/12/5/261
1.Moved registering the hrtimer based broadcast from timekeeping code
to an early_initcall.
Changes from V2
On 12/08/2014 04:18 PM, Mark Rutland wrote:
> Hi Preeti,
>
> On Mon, Dec 08, 2014 at 06:55:43AM +0000, Preeti U Murthy wrote:
>> Commit 5d1638acb9f6 ('tick: Introduce hrtimer based broadcast') added a
>> hrtimer based broadcast mode for those platforms in which local tim
On 12/08/2014 04:18 PM, Mark Rutland wrote:
Hi Preeti,
On Mon, Dec 08, 2014 at 06:55:43AM +, Preeti U Murthy wrote:
Commit 5d1638acb9f6 ('tick: Introduce hrtimer based broadcast') added a
hrtimer based broadcast mode for those platforms in which local timers stop
when CPUs enter deep
. While at it, give a name to this mode of broadcast which was
missing all along.
Signed-off-by: Preeti U Murthy pre...@linux.vnet.ibm.com
Tested-by: Mark Rutland mark.rutl...@arm.com
---
Changes from V1: https://lkml.org/lkml/2014/12/5/261
1.Moved registering the hrtimer based broadcast from
.
Signed-off-by: Preeti U Murthy
---
Changes from V1: https://lkml.org/lkml/2014/12/5/261
1.Moved registering the hrtimer based broadcast from timekeeping code
to an early_initcall.
arch/arm64/kernel/time.c |2 --
arch/powerpc/kernel/time.c |1 -
include/linux
s been
initialized, which is good since we need them. The broadcast hrtimer
will thus only get registered as a broadcast device if no other clock
device has managed to register itself as one.
Let me send out a V2.
Thanks
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line "u
managed to register itself as one.
Let me send out a V2.
Thanks
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
.
Signed-off-by: Preeti U Murthy pre...@linux.vnet.ibm.com
---
Changes from V1: https://lkml.org/lkml/2014/12/5/261
1.Moved registering the hrtimer based broadcast from timekeeping code
to an early_initcall.
arch/arm64/kernel/time.c |2 --
arch/powerpc/kernel/time.c |1
the help of the
broadcast clock device without checking for its existence. Registering a default
broadcast mode will handle such buggy cases properly.
Signed-off-by: Preeti U Murthy
---
arch/arm64/kernel/time.c |2 --
arch/powerpc/kernel/time.c |1 -
kernel/time/timekeeping.c |4
gt; A real broadcast-capable clock event device will take preference if
> present, so we don't need to add board-specific code to only register
> this in certain conditions.
Hmm.. this makes sense to me. Let me send out a patch to do this.
Regards
Preeti U Murthy
>
> Mark.
>
>> ---
preference if
present, so we don't need to add board-specific code to only register
this in certain conditions.
Hmm.. this makes sense to me. Let me send out a patch to do this.
Regards
Preeti U Murthy
Mark.
---
arch/arm/mach-imx/mach-ls1021a.c | 12
1 file changed, 12
the help of the
broadcast clock device without checking for its existence. Registering a default
broadcast mode will handle such buggy cases properly.
Signed-off-by: Preeti U Murthy pre...@linux.vnet.ibm.com
---
arch/arm64/kernel/time.c |2 --
arch/powerpc/kernel/time.c |1 -
kernel
re of frequency scaling
each time and there is no need of explicit synchronization between the
policy cpus to do this.
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info
the
policy cpus to do this.
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
. The power numbers have very little
variation between the runs with and without the patchset.
Thanks
Regards
Preeti U Murthy
On 11/25/2014 04:47 PM, Shreyas B. Prabhu wrote:
> Deep idle states like sleep and winkle are per core idle states. A core
> enters these states only when all the threads
. The power numbers have very little
variation between the runs with and without the patchset.
Thanks
Regards
Preeti U Murthy
On 11/25/2014 04:47 PM, Shreyas B. Prabhu wrote:
Deep idle states like sleep and winkle are per core idle states. A core
enters these states only when all the threads enter
x 61ed862cdd37..957a04951ef0 100644
> --- a/kernel/time/timer_list.c
> +++ b/kernel/time/timer_list.c
> @@ -229,7 +229,10 @@ print_tickdevice(struct seq_file *m, struct tick_device
> *td, int cpu)
> SEQ_printf(m, "\n");
>
> SEQ_printf(m, " set_mod
)
+ print_name_offset(m, dev-set_dev_mode);
+ else
+ print_name_offset(m, dev-set_mode);
SEQ_printf(m, \n);
SEQ_printf(m, event_handler: );
Reviewed-by: Preeti U Murthy pre...@linux.vnet.ibm.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Hi Joel,
On 11/19/2014 08:04 AM, Joel Stanley wrote:
> Hey Preeti,
>
> On Tue, Nov 18, 2014 at 5:26 PM, Preeti U Murthy
> wrote:
>> Commit dcb18694 "Fix ipi on palmeto" disabled fastsleep at boot time.
>
> I couldn't find this commit in any tree; upstream, mpe
Hi Joel,
On 11/19/2014 08:04 AM, Joel Stanley wrote:
Hey Preeti,
On Tue, Nov 18, 2014 at 5:26 PM, Preeti U Murthy
pre...@linux.vnet.ibm.com wrote:
Commit dcb18694 Fix ipi on palmeto disabled fastsleep at boot time.
I couldn't find this commit in any tree; upstream, mpe's next, nor
Commit dcb18694 "Fix ipi on palmeto" disabled fastsleep at boot time.
Revert this commit since we no longer need this fix. However we can
continue to use powersave_nap parameter to control entry into deep
idle states beyond snooze.
Signed-off-by: Preeti U. Murthy
---
drivers/cpuid
Commit dcb18694 Fix ipi on palmeto disabled fastsleep at boot time.
Revert this commit since we no longer need this fix. However we can
continue to use powersave_nap parameter to control entry into deep
idle states beyond snooze.
Signed-off-by: Preeti U. Murthy pre...@linux.vnet.ibm.com
t.
> + * b. While the last thread in the core is saving the core state, it
> + * prevent a different thread from waking up.
The above two points are useful. As far as I see besides explaining the
bits of core_idle_state structure and the purpose of lock bit the rest
of the comments is redundant. A git-blame will let people know why all
this is needed. The comment section should not be used up for this
purpose IMO.
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 11/10/2014 08:47 PM, Peter Zijlstra wrote:
> On Mon, Nov 10, 2014 at 07:50:22PM +0530, Preeti U Murthy wrote:
>> Hi Peter,
>>
>> On 11/10/2014 05:59 PM, Peter Zijlstra wrote:
>>> On Fri, Nov 07, 2014 at 03:31:22PM +0100, Daniel Lezcano wrote:
>>>>
On 11/10/2014 08:47 PM, Peter Zijlstra wrote:
On Mon, Nov 10, 2014 at 07:50:22PM +0530, Preeti U Murthy wrote:
Hi Peter,
On 11/10/2014 05:59 PM, Peter Zijlstra wrote:
On Fri, Nov 07, 2014 at 03:31:22PM +0100, Daniel Lezcano wrote:
The poll function is called when a timer expired or if we
. As far as I see besides explaining the
bits of core_idle_state structure and the purpose of lock bit the rest
of the comments is redundant. A git-blame will let people know why all
this is needed. The comment section should not be used up for this
purpose IMO.
Regards
Preeti U Murthy
the logic of checking the
exit_latency, we thought it would be simpler to call into an arch
defined polling idle loop under the above circumstances. If that is no
better we could fall back to cpuidle_idle_loop().
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line "unsu
checks on any debug parameters such as powersave_nap .We will then only
need to check for powersave_nap == 0 and return only if that is the
case. This check is still required since the user can disable all deep
idle states by setting powersave_nap to 0.
Regards
Preeti U Murthy
On 10/27/2014 06:56 PM
checks on any debug parameters such as powersave_nap .We will then only
need to check for powersave_nap == 0 and return only if that is the
case. This check is still required since the user can disable all deep
idle states by setting powersave_nap to 0.
Regards
Preeti U Murthy
On 10/27/2014 06:56 PM
the above circumstances. If that is no
better we could fall back to cpuidle_idle_loop().
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
t; This patch does not change the current behavior.
>
> Signed-off-by: Daniel Lezcano
> Acked-by: Nicolas Pitre
> Reviewed-by: Len Brown
> ---
This patch looks good to me as well.
Reviewed-by: Preeti U. Murthy
--
To unsubscribe from this list: send the line "unsubscribe linux-kern
or an opportunity to reflect on the outcome
>*/
> - cpuidle_reflect(dev, entered_state);
> + if (entered_state >= 0)
> + cpuidle_reflect(dev, entered_state);
>
> exit_idle:
> __current_set_polling();
>
Reviewed-by: Preeti U. Murthy
--
To unsubscr
ces the latency constraint specified
> externally, so one more step to the cpuidle/scheduler integration.
>
> Signed-off-by: Daniel Lezcano
> Acked-by: Nicolas Pitre
> Acked-by: Peter Zijlstra (Intel)
> Reviewed-by: Len Brown
> ---
Reviewed-by: Preeti U Murthy
Regards
cpu_idle_poll(void)
> +{
> + rcu_idle_enter();
> + trace_cpu_idle_rcuidle(0, smp_processor_id());
> + arch_cpu_idle_poll();
> + trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, smp_processor_id());
> + rcu_idle_exit();
> + return 1;
> +}
> +
> /**
> * cpuidle_idle_ca
();
+ return 1;
+}
+
/**
* cpuidle_idle_call - the main idle function
*
Thanks Daniel!
Reviewed-by: Preeti U. Murthy pre...@linux.vnet.ibm.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
Acked-by: Nicolas Pitre n...@linaro.org
Acked-by: Peter Zijlstra (Intel) pet...@infradead.org
Reviewed-by: Len Brown len.br...@intel.com
---
Reviewed-by: Preeti U Murthy pre...@linux.vnet.ibm.com
Regards
Preeti U Murthy
--
To unsubscribe
:
__current_set_polling();
Reviewed-by: Preeti U. Murthy pre...@linux.vnet.ibm.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
the current behavior.
Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org
Acked-by: Nicolas Pitre n...@linaro.org
Reviewed-by: Len Brown len.br...@intel.com
---
This patch looks good to me as well.
Reviewed-by: Preeti U. Murthy
--
To unsubscribe from this list: send the line unsubscribe
add the function in the core
PowerPC code. If arch does not define this function it will fall back to
cpu_idle_loop(). Fair enough?
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel
On 11/06/2014 05:57 PM, Daniel Lezcano wrote:
> On 11/06/2014 05:08 AM, Preeti U Murthy wrote:
>> On 11/05/2014 07:58 PM, Daniel Lezcano wrote:
>>> On 10/29/2014 03:01 AM, Preeti U Murthy wrote:
>>>> On 10/29/2014 12:29 AM, Daniel Lezcano wrote:
>>>>>
On 11/06/2014 05:57 PM, Daniel Lezcano wrote:
On 11/06/2014 05:08 AM, Preeti U Murthy wrote:
On 11/05/2014 07:58 PM, Daniel Lezcano wrote:
On 10/29/2014 03:01 AM, Preeti U Murthy wrote:
On 10/29/2014 12:29 AM, Daniel Lezcano wrote:
On 10/28/2014 04:51 AM, Preeti Murthy wrote:
Hi Daniel
this function it will fall back to
cpu_idle_loop(). Fair enough?
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
On 11/05/2014 07:58 PM, Daniel Lezcano wrote:
> On 10/29/2014 03:01 AM, Preeti U Murthy wrote:
>> On 10/29/2014 12:29 AM, Daniel Lezcano wrote:
>>> On 10/28/2014 04:51 AM, Preeti Murthy wrote:
>>>> Hi Daniel,
>>>>
>>>> On Thu, Oct 23, 2
On 11/05/2014 07:58 PM, Daniel Lezcano wrote:
On 10/29/2014 03:01 AM, Preeti U Murthy wrote:
On 10/29/2014 12:29 AM, Daniel Lezcano wrote:
On 10/28/2014 04:51 AM, Preeti Murthy wrote:
Hi Daniel,
On Thu, Oct 23, 2014 at 2:31 PM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
When the pmqos
f and
include the arch specific cpu_idle_poll() for them.
But by having a check on the exit_latency, you are claiming that since
the driver's 0th idle state is no better than the generic idle loop in
cases of 0 latency req, we are better off calling the latter, which
looks reasonable. That way you don't have to bother about worsening the
idle loop behavior on any other driver.
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
>>> + data->needs_update = 1;
>>
>> Why is the last_state_idx not getting updated ?
>
> Oups, right. This is missing.
>
> Thanks for pointing this out.
>
> By the way, I don't think a back end driver is changing the selected
> state currently an
want to remove the last_state_idx update in
ladder_reflect() also?
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
the generic idle loop in
cases of 0 latency req, we are better off calling the latter, which
looks reasonable. That way you don't have to bother about worsening the
idle loop behavior on any other driver.
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
with reality except
for the first entry.
Signed-off-by: Preeti U Murthy
---
Do we still need this workaround? Or can we get rid of the check
on powersave_nap altogether?
---
drivers/cpuidle/cpuidle-powernv.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpuidle
with reality except
for the first entry.
Signed-off-by: Preeti U Murthy pre...@linux.vnet.ibm.com
---
Do we still need this workaround? Or can we get rid of the check
on powersave_nap altogether?
---
drivers/cpuidle/cpuidle-powernv.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
/* track cpus that need to be re-evaluated */
> + cpumask_set_cpu(cpu_of(rq_of(cfs_rq)), _cpus);
All the cfs_rqs that you iterate through here will belong to the same
rq/cpu right?
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
?
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
a state loss will not enter into KVM since the
HSTATE_HWTHREAD_STATE is not yet set. It continues on to restore the
lost state.
This thread sets the HSTATE_HWTHREAD_STATE and wakes up the remaining
threads in the core. These sibling threads enter kvm directly not
requiring to restore lost state s
On 10/08/2014 03:48 PM, Peter Zijlstra wrote:
> On Wed, Oct 08, 2014 at 03:07:51PM +0530, Preeti U Murthy wrote:
>
>>> I still completely hate all that.. It basically makes cpusets useless,
>>> they no longer guarantee anything, it makes then an optional placement
>&g
On 10/08/2014 03:48 PM, Peter Zijlstra wrote:
On Wed, Oct 08, 2014 at 03:07:51PM +0530, Preeti U Murthy wrote:
I still completely hate all that.. It basically makes cpusets useless,
they no longer guarantee anything, it makes then an optional placement
hint instead.
Why do you say
thread has restored it
anyway. So we are safe. We will certainly add a comment there.
Thanks
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
301 - 400 of 1248 matches
Mail list logo
