On 06/26/2015 06:08 PM, Thomas Gleixner wrote:
> On Fri, 26 Jun 2015, Preeti U Murthy wrote:
>> On 06/26/2015 01:17 PM, Thomas Gleixner wrote:
>>> if (state == TICK_BROADCAST_ENTER) {
>>> + /*
>>> +* If the cu
On 06/26/2015 05:20 PM, Thomas Gleixner wrote:
> On Fri, 26 Jun 2015, Preeti U Murthy wrote:
>> On 06/26/2015 01:17 PM, Thomas Gleixner wrote:
>>> On Fri, 26 Jun 2015, Preeti U Murthy wrote:
>>>> What about the case where GENERIC_CLOCKEVENTS_BROADCAST=y and
>
* shutdown.
> - */
> - ret = broadcast_needs_cpu(bc, cpu);
> - if (ret)
> - cpumask_clear_cpu(cpu, tick_broadcast_oneshot_mask);
> } else {
> if (cpumask_test_and_clear_cpu(cpu,
> tick_broadcast_oneshot_mask)) {
>
On 06/26/2015 01:17 PM, Thomas Gleixner wrote:
> On Fri, 26 Jun 2015, Preeti U Murthy wrote:
>> What about the case where GENERIC_CLOCKEVENTS_BROADCAST=y and
>> TICK_ONESHOT=n (HZ_PERIODIC=y) ? Have you tested this ?
>>
>> This will hang the kernel at boot if you
On 06/26/2015 05:20 PM, Thomas Gleixner wrote:
On Fri, 26 Jun 2015, Preeti U Murthy wrote:
On 06/26/2015 01:17 PM, Thomas Gleixner wrote:
On Fri, 26 Jun 2015, Preeti U Murthy wrote:
What about the case where GENERIC_CLOCKEVENTS_BROADCAST=y and
TICK_ONESHOT=n (HZ_PERIODIC=y) ? Have you tested
On 06/26/2015 06:08 PM, Thomas Gleixner wrote:
On Fri, 26 Jun 2015, Preeti U Murthy wrote:
On 06/26/2015 01:17 PM, Thomas Gleixner wrote:
if (state == TICK_BROADCAST_ENTER) {
+ /*
+* If the current CPU owns the hrtimer broadcast
+* mechanism, it cannot
On 06/26/2015 01:17 PM, Thomas Gleixner wrote:
On Fri, 26 Jun 2015, Preeti U Murthy wrote:
What about the case where GENERIC_CLOCKEVENTS_BROADCAST=y and
TICK_ONESHOT=n (HZ_PERIODIC=y) ? Have you tested this ?
This will hang the kernel at boot if you are using the hrtimer mode of
broadcast
tick_broadcast_oneshot_available(void)
return bc ? bc-features CLOCK_EVT_FEAT_ONESHOT : false;
}
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
re shutdown
when the cpuidle driver registers itself, on finding out that there are
idle states where local tick devices stop. The broadcast tick device is
then in charge of waking up the cpus at every period. In hrtimer mode of
broadcast, there is no such real device and we hang.
There was a patch sent
diff --git a/kernel/time/tick-sched.h b/kernel/time/tick-sched.h
> index 42fdf4958bcc..a4a8d4e9baa1 100644
> --- a/kernel/time/tick-sched.h
> +++ b/kernel/time/tick-sched.h
> @@ -71,4 +71,14 @@ extern void tick_cancel_sched_timer(int cpu);
> static inline void tick_cancel_sched_timer(
-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://www.tux.org/lkml/
where local tick devices stop. The broadcast tick device is
then in charge of waking up the cpus at every period. In hrtimer mode of
broadcast, there is no such real device and we hang.
There was a patch sent out recently to fix this on powerpc.
https://lkml.org/lkml/2015/6/24/42
Regards
Preeti U
hout TICK_ONESHOT, the
>> machine will hang.
>
> OK, which -stable? All of them or any specific series?
This needs to go into stable/linux-3.19.y,
stable/linux-4.0.y, stable/linux-4.1.y.
Thanks
Regards
Preeti U Murthy
>
> Rafael
>
e CPUs which are not Full Dynticks
> in FULL_NOHZ configured systems. It will not bring about functional
> changes if NOHZ_FULL is not configured, because is_housekeeping_cpu()
> always returns true in CONFIG_NO_HZ_FULL=n.
>
> Signed-off by: Vatika Harlalka
> ---
Reviewed-by: Preet
on the hrtimer
mode of broadcast in periodic mode. This patch takes care of doing this
on powerpc. The cpus would not have entered into such deep cpuidle
states in periodic mode on powerpc anyway. So there is no loss here.
Signed-off-by: Preeti U Murthy
---
drivers/cpuidle/cpuidle-powernv.c | 15
are not Full Dynticks
in FULL_NOHZ configured systems. It will not bring about functional
changes if NOHZ_FULL is not configured, because is_housekeeping_cpu()
always returns true in CONFIG_NO_HZ_FULL=n.
Signed-off by: Vatika Harlalka vatikaharla...@gmail.com
---
Reviewed-by: Preeti U Murthy pre
on the hrtimer
mode of broadcast in periodic mode. This patch takes care of doing this
on powerpc. The cpus would not have entered into such deep cpuidle
states in periodic mode on powerpc anyway. So there is no loss here.
Signed-off-by: Preeti U Murthy pre...@linux.vnet.ibm.com
---
drivers/cpuidle
, the
machine will hang.
OK, which -stable? All of them or any specific series?
This needs to go into stable/linux-3.19.y,
stable/linux-4.0.y, stable/linux-4.1.y.
Thanks
Regards
Preeti U Murthy
Rafael
___
Linuxppc-dev mailing list
linuxppc
ves a chance to the cpuidle governor to re-evaluate the
> last idle state of the cpu to promote it to deeper idle states.
>
> Signed-off-by: Shilpasri G Bhat
> ---
Reviewed-by: Preeti U Murthy
> Changes from v1:
> -Modified commit message
>
> drivers/cpuidle/cpuidle-po
A reminder to pick this series up for stable-4.0
On 05/13/2015 05:19 PM, Preeti U Murthy wrote:
> The intention was to backport only PATCH[5/5]: clockevents: Fix
> cpu_down() race for hrtimer based broadcasting,
>
> but this depends on commits upstream which did cleanup and
>
to the cpuidle governor to re-evaluate the
last idle state of the cpu to promote it to deeper idle states.
Signed-off-by: Shilpasri G Bhat shilpa.b...@linux.vnet.ibm.com
---
Reviewed-by: Preeti U Murthy pre...@linux.vnet.ibm.com
Changes from v1:
-Modified commit message
drivers/cpuidle/cpuidle
A reminder to pick this series up for stable-4.0
On 05/13/2015 05:19 PM, Preeti U Murthy wrote:
The intention was to backport only PATCH[5/5]: clockevents: Fix
cpu_down() race for hrtimer based broadcasting,
but this depends on commits upstream which did cleanup and
reorganization of code
; not to preempt the currently running task to switch to
> it yet, but we will want to preempt the currently running
> task at a later point in time?
+1. This is not taken care of as far as I can see too.
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/
man Khandual
> Cc: Stephane Eranian
> Cc: Preeti U Murthy
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Signed-off-by: Madhavan Srinivasan
> ---
> +static void nest_change_cpu_context(int old_cpu, int new_cpu)
> +{
> + int i;
> +
> + if
on a CPU, but we decide
not to preempt the currently running task to switch to
it yet, but we will want to preempt the currently running
task at a later point in time?
+1. This is not taken care of as far as I can see too.
Regards
Preeti U Murthy
--
To unsubscribe from this list: send
suka...@linux.vnet.ibm.com
Cc: Anshuman Khandual khand...@linux.vnet.ibm.com
Cc: Stephane Eranian eran...@google.com
Cc: Preeti U Murthy pre...@linux.vnet.ibm.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Signed-off-by: Madhavan Srinivasan ma
atleast on powerpc after handling an interrupt, we will
call irq_exit() and reevaluate starting of ticks. So in our case even if
scheduler_ipi() callers do not call irq_exit(), it will be called after
handling the reschedule interrupt.
Regards
Preeti U Murthy
>
--
To unsubscribe from this l
x cpu timers ? These call sites
seem to be concerned about specifically waking up nohz_full cpus as far
as I can see. IOW there is no scheduling ipi that we can fall back on in
these paths.
> careful review of resched_curr() callers.
>
Regards
Preeti U Murthy
--
To unsubscribe from this l
x cpu timers ? These call sites
seem to be concerned about specifically waking up nohz_full cpus as far
as I can see. IOW there is no scheduling ipi that we can fall back on in
these paths.
> careful review of resched_curr() callers.
>
Regards
Preeti U Murthy
--
To unsubscribe from this l
? These call sites
seem to be concerned about specifically waking up nohz_full cpus as far
as I can see. IOW there is no scheduling ipi that we can fall back on in
these paths.
careful review of resched_curr() callers.
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line unsubscribe
? These call sites
seem to be concerned about specifically waking up nohz_full cpus as far
as I can see. IOW there is no scheduling ipi that we can fall back on in
these paths.
careful review of resched_curr() callers.
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line unsubscribe
if
scheduler_ipi() callers do not call irq_exit(), it will be called after
handling the reschedule interrupt.
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
idle task was there
in the first place in the below code paths. It would help if you could
clarify this in the changelog as well.
>
> So lets remove it.
>
> Cc: Christoph Lameter
> Cc: Ingo Molnar
> Cc; John Stultz
> Cc: Peter Zijlstra
> Cc: Preeti U Murthy
> Cc: Rik v
on ts-inidle would have
succeeded in tick_irq_exit() and we would not have reached this function
at all, isn't it? So here too I am unable to understand why we had it in
the first place.
Regards
Preeti U Murthy
return;
if (!ts-tick_stopped ts-nohz_mode == NOHZ_MODE_INACTIVE
On 06/02/2015 11:57 AM, Viresh Kumar wrote:
> On 02-06-15, 11:50, Preeti U Murthy wrote:
>> CPU0CPU1
>>
>> store* store*
>>
>> lock(policy 1) lock(policy 2)
>> cpufreq_set_policy() cpufr
On 06/02/2015 11:41 AM, Viresh Kumar wrote:
> On 02-06-15, 11:33, Preeti U Murthy wrote:
>> No, dbs_data is a governor wide data structure and not a policy wide
>
> Yeah, that's the common part which I was referring to. But normally
> its just read for policies in START/STOP, th
On 06/02/2015 11:09 AM, Viresh Kumar wrote:
> On 02-06-15, 11:01, Preeti U Murthy wrote:
>> How will a policy lock help here at all, when cpus from multiple
>> policies are calling into __cpufreq_governor() ? How will a policy lock
>> serialize their entry into cpufreq_gov
On 06/02/2015 11:57 AM, Viresh Kumar wrote:
On 02-06-15, 11:50, Preeti U Murthy wrote:
CPU0CPU1
store* store*
lock(policy 1) lock(policy 2)
cpufreq_set_policy() cpufreq_set_policy()
EXIT() :
dbs-data-usage_count--
INIT
On 06/02/2015 11:41 AM, Viresh Kumar wrote:
On 02-06-15, 11:33, Preeti U Murthy wrote:
No, dbs_data is a governor wide data structure and not a policy wide
Yeah, that's the common part which I was referring to. But normally
its just read for policies in START/STOP, they just update per-cpu
On 06/02/2015 11:09 AM, Viresh Kumar wrote:
On 02-06-15, 11:01, Preeti U Murthy wrote:
How will a policy lock help here at all, when cpus from multiple
policies are calling into __cpufreq_governor() ? How will a policy lock
serialize their entry into cpufreq_governor_dbs() ?
So different
On 06/01/2015 12:49 PM, Viresh Kumar wrote:
> On 01-06-15, 01:40, Preeti U Murthy wrote:
>
> I have to mention that this is somewhat inspired by:
>
> https://git.linaro.org/people/viresh.kumar/linux.git/commit/1e37f1d6ae12f5896e4e216f986762c3050129a5
>
> and I was waitin
On 06/01/2015 12:49 PM, Viresh Kumar wrote:
> On 01-06-15, 01:40, Preeti U Murthy wrote:
>
> I have to mention that this is somewhat inspired by:
>
> https://git.linaro.org/people/viresh.kumar/linux.git/commit/1e37f1d6ae12f5896e4e216f986762c3050129a5
>
> and I was waitin
rallel cpufreq operations themselves.
This RFC patch brings forth potential issues and possible approaches to
solutions.
[1] http://comments.gmane.org/gmane.linux.power-management.general/49337
Signed-off-by: Preeti U Murthy
---
drivers/cpufreq/cpufreq.c
cpufreq operations themselves.
This RFC patch brings forth potential issues and possible approaches to
solutions.
[1] http://comments.gmane.org/gmane.linux.power-management.general/49337
Signed-off-by: Preeti U Murthy pre...@linux.vnet.ibm.com
---
drivers/cpufreq/cpufreq.c | 68
On 06/01/2015 12:49 PM, Viresh Kumar wrote:
On 01-06-15, 01:40, Preeti U Murthy wrote:
I have to mention that this is somewhat inspired by:
https://git.linaro.org/people/viresh.kumar/linux.git/commit/1e37f1d6ae12f5896e4e216f986762c3050129a5
and I was waiting to finish some core-changes
On 06/01/2015 12:49 PM, Viresh Kumar wrote:
On 01-06-15, 01:40, Preeti U Murthy wrote:
I have to mention that this is somewhat inspired by:
https://git.linaro.org/people/viresh.kumar/linux.git/commit/1e37f1d6ae12f5896e4e216f986762c3050129a5
and I was waiting to finish some core-changes
On 05/30/2015 11:31 AM, Vaidyanathan Srinivasan wrote:
> * Preeti U Murthy [2015-05-29 19:17:17]:
>
> [snip]
>
>>> + if (max_idle_state > 1) {
>>> + snooze_timeout_en = true;
>>> + snooze_timeout
On 05/30/2015 11:31 AM, Vaidyanathan Srinivasan wrote:
* Preeti U Murthy pre...@linux.vnet.ibm.com [2015-05-29 19:17:17]:
[snip]
+ if (max_idle_state 1) {
+ snooze_timeout_en = true;
+ snooze_timeout = cpuidle_state_table[1].target_residency
)
> } else
> return -ENODEV;
>
> + if (max_idle_state > 1) {
> + snooze_timeout_en = true;
> + snooze_timeout = cpuidle_state_table[1].target_residency *
> + tb_ticks_per_usec;
> + }
Any idea why we don'
*
+ tb_ticks_per_usec;
+ }
Any idea why we don't have snooze defined on the shared lpar configuration ?
Regards
Preeti U Murthy
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
E_DRIVER_STATE_START - 1;
> + int i, ret = -ENXIO;
>
> - for (i = CPUIDLE_DRIVER_STATE_START; i < drv->state_count; i++) {
> + for (i = 0; i < drv->state_count; i++) {
> struct cpuidle_state *s = >states[i];
> struct cpuidl
On 05/27/2015 07:27 PM, Rafael J. Wysocki wrote:
> On Wed, May 27, 2015 at 2:25 PM, Daniel Lezcano
> wrote:
>> On 05/27/2015 01:31 PM, Preeti U Murthy wrote:
>>>
>>> On 05/27/2015 07:06 AM, Rafael J. Wysocki wrote:
>>>>
>>>> From: Rafael J. Wy
lling state
during suspend, this will cause an issue, won't it? This also gets me
wondering if polling state is an acceptable idle state during suspend,
given that the drivers with ARCH_HAS_CPU_RELAX permit entry into it
during suspend today. I would expect the cpus to be in a hardware
defined idle stat
the cpus to be in a hardware
defined idle state.
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
On 05/27/2015 07:27 PM, Rafael J. Wysocki wrote:
On Wed, May 27, 2015 at 2:25 PM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
On 05/27/2015 01:31 PM, Preeti U Murthy wrote:
On 05/27/2015 07:06 AM, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
[i];
struct cpuidle_state_usage *su = dev-states_usage[i];
Reviewed-by: Preeti U Murthy pre...@linux.vnet.ibm.com
--
To unsubscribe from this list: send the line unsubscribe linux-pm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
it has no impact on the condition since tasks can migrate
> + * only from online cpus to other online cpus. Thus its safe
> + * to use raw_smp_processor_id.
> + */
> + TP_CONDITION(cpu_online(raw_smp_processor_id())),
>
> TP_STRUCT__entry(
> __field(un
, pfn )
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
active just because the timer is supposed to fire 5 minutes from now,
which is precisely what happens if we go the genpd way.
Hence I don't think we can trivially club timers with genpd unless we
have a way to power the timer PM domain down, depending on when it is
supposed to fire, in which case
timers with genpd unless we
have a way to power the timer PM domain down, depending on when it is
supposed to fire, in which case we will merely be replicating the
cpuidle governor code.
Regards
Preeti U Murthy
So question is whether or not this is actually really more
straightforward than
On 05/10/2015 04:45 AM, Rafael J. Wysocki wrote:
> On Saturday, May 09, 2015 10:33:05 PM Rafael J. Wysocki wrote:
>> On Saturday, May 09, 2015 10:11:41 PM Rafael J. Wysocki wrote:
>>> On Saturday, May 09, 2015 11:19:16 AM Preeti U Murthy wrote:
>>>> Hi Rafael,
&g
On 05/10/2015 04:45 AM, Rafael J. Wysocki wrote:
> On Saturday, May 09, 2015 10:33:05 PM Rafael J. Wysocki wrote:
>> On Saturday, May 09, 2015 10:11:41 PM Rafael J. Wysocki wrote:
>>> On Saturday, May 09, 2015 11:19:16 AM Preeti U Murthy wrote:
>>>> Hi Rafael,
&g
On 05/10/2015 04:45 AM, Rafael J. Wysocki wrote:
On Saturday, May 09, 2015 10:33:05 PM Rafael J. Wysocki wrote:
On Saturday, May 09, 2015 10:11:41 PM Rafael J. Wysocki wrote:
On Saturday, May 09, 2015 11:19:16 AM Preeti U Murthy wrote:
Hi Rafael,
On 05/08/2015 07:48 PM, Rafael J. Wysocki
On 05/10/2015 04:45 AM, Rafael J. Wysocki wrote:
On Saturday, May 09, 2015 10:33:05 PM Rafael J. Wysocki wrote:
On Saturday, May 09, 2015 10:11:41 PM Rafael J. Wysocki wrote:
On Saturday, May 09, 2015 11:19:16 AM Preeti U Murthy wrote:
Hi Rafael,
On 05/08/2015 07:48 PM, Rafael J. Wysocki
est_state(drv, dev, true, drv->state_count, 0);
> if (index >= 0)
> enter_freeze_proper(drv, dev, index);
>
> @@ -168,8 +170,13 @@ int cpuidle_enter_state(struct cpuidle_d
>* CPU as a broadcast timer, this call may fail if it is not available.
>
Commit-ID: 663fdcbee0a656cdaef934e7f50e6c2670373bc9
Gitweb: http://git.kernel.org/tip/663fdcbee0a656cdaef934e7f50e6c2670373bc9
Author: Preeti U Murthy
AuthorDate: Thu, 30 Apr 2015 17:27:21 +0530
Committer: Ingo Molnar
CommitDate: Fri, 8 May 2015 12:28:53 +0200
kernel: Replace
On 05/08/2015 02:20 AM, Rafael J. Wysocki wrote:
> On Thursday, May 07, 2015 11:17:21 PM Preeti U Murthy wrote:
>> When a CPU has to enter an idle state where tick stops, it makes a call
>> to tick_broadcast_enter(). The call will fail if this CPU is the
>> broadc
driver, else the
rq->idle_state will be set wrong.
Signed-off-by: Preeti U Murthy
---
Changes from V2: https://lkml.org/lkml/2015/5/7/78
Introduce a function in cpuidle core to select an idle state where ticks do not
stop rather than going through the governors.
Changes from V1: https://lkml.
On 05/08/2015 02:20 AM, Rafael J. Wysocki wrote:
On Thursday, May 07, 2015 11:17:21 PM Preeti U Murthy wrote:
When a CPU has to enter an idle state where tick stops, it makes a call
to tick_broadcast_enter(). The call will fail if this CPU is the
broadcast CPU. Today, under such a circumstance
driver, else the
rq-idle_state will be set wrong.
Signed-off-by: Preeti U Murthy pre...@linux.vnet.ibm.com
---
Changes from V2: https://lkml.org/lkml/2015/5/7/78
Introduce a function in cpuidle core to select an idle state where ticks do not
stop rather than going through the governors.
Changes from
Commit-ID: 663fdcbee0a656cdaef934e7f50e6c2670373bc9
Gitweb: http://git.kernel.org/tip/663fdcbee0a656cdaef934e7f50e6c2670373bc9
Author: Preeti U Murthy pre...@linux.vnet.ibm.com
AuthorDate: Thu, 30 Apr 2015 17:27:21 +0530
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Fri, 8 May 2015
,
+CPUIDLE_FLAG_TIMER_STOP);
+ if (index 0) {
+ default_idle_call();
+ return -EBUSY;
+ }
+ target_state = drv-states[index];
}
trace_cpu_idle_rcuidle(index, dev-cpu);
Regards
Preeti U Murthy
On 05/08/2015 02:29 AM, Rafael J. Wysocki wrote:
> On Thursday, May 07, 2015 05:49:22 PM Preeti U Murthy wrote:
>> On 05/05/2015 02:11 PM, Preeti U Murthy wrote:
>>> On 05/05/2015 12:03 PM, Shilpasri G Bhat wrote:
>>>> Hi Preeti,
>>>>
>>>> O
On 05/07/2015 11:09 PM, Preeti U Murthy wrote:
> When a CPU has to enter an idle state where tick stops, it makes a call
> to tick_broadcast_enter(). The call will fail if this CPU is the
> broadcast CPU. Today, under such a circumstance, the arch cpuidle code
> hand
On 05/07/2015 03:26 PM, Sudeep Holla wrote:
> Hi Preeti,
>
> On 07/05/15 06:26, Preeti U Murthy wrote:
>> When a CPU has to enter an idle state where tick stops, it makes a call
>> to tick_broadcast_enter(). The call will fail if this CPU is the
>> broadcast CPU. Today
from the
core to the cpuidle driver, else the rq->idle_state will be set wrong.
Signed-off-by: Preeti U Murthy
---
Changes from V1: https://lkml.org/lkml/2015/5/7/24
Rebased on the latest linux-pm/bleeding-edge
drivers/cpuidle/cpuidle.c | 21 +
drivers/cpui
from the
core to the cpuidle driver, else the rq->idle_state will be set wrong.
Signed-off-by: Preeti U Murthy
---
Rebased on the latest linux-pm/bleeding-edge
drivers/cpuidle/cpuidle.c | 21 +
drivers/cpuidle/governors/ladder.c | 13 ++---
drivers/cpui
On 05/05/2015 02:11 PM, Preeti U Murthy wrote:
> On 05/05/2015 12:03 PM, Shilpasri G Bhat wrote:
>> Hi Preeti,
>>
>> On 05/05/2015 09:30 AM, Preeti U Murthy wrote:
>>> Hi Shilpa,
>>>
>>> On 05/04/2015 02:24 PM, Shilpasri G Bhat wrote:
>>
On 05/07/2015 04:05 PM, Shilpasri G Bhat wrote:
>
>
> On 05/05/2015 02:08 PM, Preeti U Murthy wrote:
>> On 05/05/2015 11:36 AM, Shilpasri G Bhat wrote:
>>> Hi Preeti,
>>>
>>> On 05/05/2015 09:21 AM, Preeti U Murthy wrote:
>>>> Hi Shilpa,
&g
On 05/07/2015 03:26 PM, Sudeep Holla wrote:
Hi Preeti,
On 07/05/15 06:26, Preeti U Murthy wrote:
When a CPU has to enter an idle state where tick stops, it makes a call
to tick_broadcast_enter(). The call will fail if this CPU is the
broadcast CPU. Today, under such a circumstance, the arch
On 05/07/2015 11:09 PM, Preeti U Murthy wrote:
When a CPU has to enter an idle state where tick stops, it makes a call
to tick_broadcast_enter(). The call will fail if this CPU is the
broadcast CPU. Today, under such a circumstance, the arch cpuidle code
handles this CPU
from the
core to the cpuidle driver, else the rq-idle_state will be set wrong.
Signed-off-by: Preeti U Murthy pre...@linux.vnet.ibm.com
---
Changes from V1: https://lkml.org/lkml/2015/5/7/24
Rebased on the latest linux-pm/bleeding-edge
drivers/cpuidle/cpuidle.c | 21
On 05/07/2015 04:05 PM, Shilpasri G Bhat wrote:
On 05/05/2015 02:08 PM, Preeti U Murthy wrote:
On 05/05/2015 11:36 AM, Shilpasri G Bhat wrote:
Hi Preeti,
On 05/05/2015 09:21 AM, Preeti U Murthy wrote:
Hi Shilpa,
On 05/04/2015 02:24 PM, Shilpasri G Bhat wrote:
The On-Chip-Controller
On 05/05/2015 02:11 PM, Preeti U Murthy wrote:
On 05/05/2015 12:03 PM, Shilpasri G Bhat wrote:
Hi Preeti,
On 05/05/2015 09:30 AM, Preeti U Murthy wrote:
Hi Shilpa,
On 05/04/2015 02:24 PM, Shilpasri G Bhat wrote:
Re-evaluate the chip's throttled state on recieving OCC_THROTTLE
notification
On 05/08/2015 02:29 AM, Rafael J. Wysocki wrote:
On Thursday, May 07, 2015 05:49:22 PM Preeti U Murthy wrote:
On 05/05/2015 02:11 PM, Preeti U Murthy wrote:
On 05/05/2015 12:03 PM, Shilpasri G Bhat wrote:
Hi Preeti,
On 05/05/2015 09:30 AM, Preeti U Murthy wrote:
Hi Shilpa,
On 05/04/2015
from the
core to the cpuidle driver, else the rq-idle_state will be set wrong.
Signed-off-by: Preeti U Murthy pre...@linux.vnet.ibm.com
---
Rebased on the latest linux-pm/bleeding-edge
drivers/cpuidle/cpuidle.c | 21 +
drivers/cpuidle/governors/ladder.c | 13
from the
core to the cpuidle driver, else the rq->idle_state will be set wrong.
Signed-off-by: Preeti U Murthy
---
Based on linux-pm/bleeding-edge
drivers/cpuidle/cpuidle.c | 21 +
drivers/cpuidle/governors/ladder.c | 13 ++---
drivers/cpuidle/govern
from the
core to the cpuidle driver, else the rq-idle_state will be set wrong.
Signed-off-by: Preeti U Murthy pre...@linux.vnet.ibm.com
---
Based on linux-pm/bleeding-edge
drivers/cpuidle/cpuidle.c | 21 +
drivers/cpuidle/governors/ladder.c | 13
;
> }
> @@ -545,6 +571,7 @@ static int init_chip_info(void)
> chips[i].throttled = false;
> cpumask_copy([i].mask, cpumask_of_node(chip[i]));
> INIT_WORK([i].throttle, powernv_cpufreq_work_fn);
> + chips[i].restore = false;
> }
>
> return 0;
>
Reviewed-by: 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 05/05/2015 12:03 PM, Shilpasri G Bhat wrote:
> Hi Preeti,
>
> On 05/05/2015 09:30 AM, Preeti U Murthy wrote:
>> Hi Shilpa,
>>
>> On 05/04/2015 02:24 PM, Shilpasri G Bhat wrote:
>>> Re-evaluate the chip's throttled state on recieving OCC_THROTTLE
>>&
Commit-ID: 1ef09cd713c90781b683a0b4e0a874803c172b1d
Gitweb: http://git.kernel.org/tip/1ef09cd713c90781b683a0b4e0a874803c172b1d
Author: Preeti U Murthy
AuthorDate: Tue, 28 Apr 2015 14:15:20 +0530
Committer: Thomas Gleixner
CommitDate: Tue, 5 May 2015 10:35:58 +0200
tick-broadcast: Fix
On 05/05/2015 11:36 AM, Shilpasri G Bhat wrote:
> Hi Preeti,
>
> On 05/05/2015 09:21 AM, Preeti U Murthy wrote:
>> Hi Shilpa,
>>
>> On 05/04/2015 02:24 PM, Shilpasri G Bhat wrote:
>>> The On-Chip-Controller(OCC) can throttle cpu frequency by reducing the
>
On 05/05/2015 11:36 AM, Shilpasri G Bhat wrote:
Hi Preeti,
On 05/05/2015 09:21 AM, Preeti U Murthy wrote:
Hi Shilpa,
On 05/04/2015 02:24 PM, Shilpasri G Bhat wrote:
The On-Chip-Controller(OCC) can throttle cpu frequency by reducing the
max allowed frequency for that chip if the chip
Commit-ID: 1ef09cd713c90781b683a0b4e0a874803c172b1d
Gitweb: http://git.kernel.org/tip/1ef09cd713c90781b683a0b4e0a874803c172b1d
Author: Preeti U Murthy pre...@linux.vnet.ibm.com
AuthorDate: Tue, 28 Apr 2015 14:15:20 +0530
Committer: Thomas Gleixner t...@linutronix.de
CommitDate: Tue, 5
On 05/05/2015 12:03 PM, Shilpasri G Bhat wrote:
Hi Preeti,
On 05/05/2015 09:30 AM, Preeti U Murthy wrote:
Hi Shilpa,
On 05/04/2015 02:24 PM, Shilpasri G Bhat wrote:
Re-evaluate the chip's throttled state on recieving OCC_THROTTLE
notification by executing *throttle_check() on any one
0;
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://www.tux.org
for (i = 0; i < nr_chips; i++)
> + if (chips[i].id == chip_id)
> + schedule_work([i].throttle);
> }
Should we not do this only when we get unthrottled so as to cross verify
if it is indeed the case ? In case of thrott
gt; @@ -414,6 +433,33 @@ static struct cpufreq_driver powernv_cpufreq_driver = {
> .attr = powernv_cpu_freq_attr,
What about the situation where although occ is active, this particular
chip has been throttled and we end up repeatedly reporting "pstate set
to safe" and &
k if Psafe_mode_active is set in PMSR. */
> next:
> - pmsr_lp = (s8)PMSR_LP(pmsr);
> - if ((pmsr_lp < powernv_pstate_info.min) ||
> - (pmsr & PMSR_PSAFE_ENABLE)) {
> + if (pmsr & PMSR_PSAFE_ENABLE) {
> thr
se if (!reason)
> + pr_info("OCC: Chip %u %s\n", (unsigned int)chip_id,
> + throttle_reason[reason]);
> + }
> + return 0;
> +}
> +
> +static struct notifier_block powernv_cpufreq_opal_nb = {
> + .notifier_call
1 - 100 of 1248 matches
Mail list logo
