On Wed, Apr 29, 2015 at 10:49 PM, Shreyas B Prabhu
wrote:
>
>
> On Wednesday 29 April 2015 10:38 PM, Steven Rostedt wrote:
>>> I am not sure if its worth the effort now. It doesn't look like any
>>> other trace point apart from the above use case will benefit from it.
>>> Only smbus_write and
Ccing Paul,
On Tue, Apr 28, 2015 at 9:21 PM, Shreyas B. Prabhu
wrote:
> Since tracepoints use RCU for protection, they must not be called on
> offline cpus. trace_mm_page_pcpu_drain can be called on an offline cpu
> in this scenario caught by LOCKDEP:
>
> ===
> [
On Wed, Apr 29, 2015 at 2:36 PM, Preeti Murthy wrote:
> Ccing Paul,
>
> On Tue, Apr 28, 2015 at 9:21 PM, Shreyas B. Prabhu
> wrote:
>> Since tracepoints use RCU for protection, they must not be called on
>> offline cpus. trace_mm_page_free can be called on an offline
Ccing Paul,
On Tue, Apr 28, 2015 at 9:21 PM, Shreyas B. Prabhu
wrote:
> Since tracepoints use RCU for protection, they must not be called on
> offline cpus. trace_mm_page_free can be called on an offline cpu in
> this scenario caught by LOCKDEP:
>
> ===
> [ INFO:
Ccing Paul,
On Tue, Apr 28, 2015 at 9:21 PM, Shreyas B. Prabhu
wrote:
> Since tracepoints use RCU for protection, they must not be called on
> offline cpus. trace_kmem_cache_free can be called on an offline cpu in
> this scenario caught by LOCKDEP:
>
> ===
> [ INFO:
Ccing Paul,
On Tue, Apr 28, 2015 at 9:21 PM, Shreyas B. Prabhu
shre...@linux.vnet.ibm.com wrote:
Since tracepoints use RCU for protection, they must not be called on
offline cpus. trace_mm_page_free can be called on an offline cpu in
this scenario caught by LOCKDEP:
Ccing Paul,
On Tue, Apr 28, 2015 at 9:21 PM, Shreyas B. Prabhu
shre...@linux.vnet.ibm.com wrote:
Since tracepoints use RCU for protection, they must not be called on
offline cpus. trace_kmem_cache_free can be called on an offline cpu in
this scenario caught by LOCKDEP:
Ccing Paul,
On Tue, Apr 28, 2015 at 9:21 PM, Shreyas B. Prabhu
shre...@linux.vnet.ibm.com wrote:
Since tracepoints use RCU for protection, they must not be called on
offline cpus. trace_mm_page_pcpu_drain can be called on an offline cpu
in this scenario caught by LOCKDEP:
On Wed, Apr 29, 2015 at 2:36 PM, Preeti Murthy preeti.l...@gmail.com wrote:
Ccing Paul,
On Tue, Apr 28, 2015 at 9:21 PM, Shreyas B. Prabhu
shre...@linux.vnet.ibm.com wrote:
Since tracepoints use RCU for protection, they must not be called on
offline cpus. trace_mm_page_free can be called
On Wed, Apr 29, 2015 at 10:49 PM, Shreyas B Prabhu
shre...@linux.vnet.ibm.com wrote:
On Wednesday 29 April 2015 10:38 PM, Steven Rostedt wrote:
I am not sure if its worth the effort now. It doesn't look like any
other trace point apart from the above use case will benefit from it.
Only
Hi Thomas,
On Tue, Dec 16, 2014 at 6:19 PM, Thomas Gleixner wrote:
> On Tue, 16 Dec 2014, Preeti U Murthy wrote:
>> As far as I can see, the primary purpose of tick_nohz_irq_enter()/exit()
>> paths was to take care of *tick stopped* cases.
>>
>> Before handling interrupts we would want jiffies
Hi Thomas,
On Tue, Dec 16, 2014 at 6:19 PM, Thomas Gleixner t...@linutronix.de wrote:
On Tue, 16 Dec 2014, Preeti U Murthy wrote:
As far as I can see, the primary purpose of tick_nohz_irq_enter()/exit()
paths was to take care of *tick stopped* cases.
Before handling interrupts we would want
On Thu, Oct 23, 2014 at 2:31 PM, Daniel Lezcano
wrote:
> In the current code, the check to reflect or not the outcoming state is done
> against the idle state which has been chosen and its value.
>
> Instead of doing a check in each of the reflect functions, just don't call
> reflect
> if
Hi Daniel,
On Mon, Oct 20, 2014 at 9:55 PM, Daniel Lezcano
wrote:
> Following the logic of the previous patch, retrieve from the idle task the
> expected timer sleep duration and pass it to the cpuidle framework.
>
> Take the opportunity to remove the unused headers in the menu.c file.
>
> This
Hi Daniel,
On Thu, Oct 23, 2014 at 2:31 PM, Daniel Lezcano
wrote:
> When the pmqos latency requirement is set to zero that means "poll in all the
> cases".
>
> That is correctly implemented on x86 but not on the other archs.
>
> As how is written the code, if the latency request is zero, the
Hi Daniel,
On Thu, Oct 23, 2014 at 2:31 PM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
When the pmqos latency requirement is set to zero that means poll in all the
cases.
That is correctly implemented on x86 but not on the other archs.
As how is written the code, if the latency request
Hi Daniel,
On Mon, Oct 20, 2014 at 9:55 PM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
Following the logic of the previous patch, retrieve from the idle task the
expected timer sleep duration and pass it to the cpuidle framework.
Take the opportunity to remove the unused headers in the
On Thu, Oct 23, 2014 at 2:31 PM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
In the current code, the check to reflect or not the outcoming state is done
against the idle state which has been chosen and its value.
Instead of doing a check in each of the reflect functions, just don't call
Hi Kirill,
Which tree is this patch based on? __migrate_task() does a
double_rq_lock/unlock() today in mainline, doesn't it? I don't
however see that in your patch.
Regards
Preeti U Murthy
On Fri, Sep 12, 2014 at 4:33 PM, Kirill Tkhai wrote:
>
> If a task is queued but not running on it rq, we
Hi Kirill,
Which tree is this patch based on? __migrate_task() does a
double_rq_lock/unlock() today in mainline, doesn't it? I don't
however see that in your patch.
Regards
Preeti U Murthy
On Fri, Sep 12, 2014 at 4:33 PM, Kirill Tkhai ktk...@parallels.com wrote:
If a task is queued but not
Hi,
On Fri, May 16, 2014 at 1:34 PM, Peter Zijlstra wrote:
> On Thu, May 15, 2014 at 03:59:20PM -0700, Ben Segall wrote:
>> task_hot checks exec_start on any runnable task, but if it has been
>> migrated since the it last ran, then exec_start is a clock_task from
>> another cpu. If the old cpu's
Hi Nicolas,
You might want to change the subject.
s/sched: remove remaining power to the CPU/
sched: remove remaining usage of cpu *power* .
The subject has to explicitly specify in some way
that it is a change made to the terminology.
Regards
Preeti U Murthy
On Thu, May 15, 2014 at 2:27 AM,
Hi Nicolas,
You might want to change the subject.
s/sched: remove remaining power to the CPU/
sched: remove remaining usage of cpu *power* .
The subject has to explicitly specify in some way
that it is a change made to the terminology.
Regards
Preeti U Murthy
On Thu, May 15, 2014 at 2:27 AM,
Hi,
On Fri, May 16, 2014 at 1:34 PM, Peter Zijlstra pet...@infradead.org wrote:
On Thu, May 15, 2014 at 03:59:20PM -0700, Ben Segall wrote:
task_hot checks exec_start on any runnable task, but if it has been
migrated since the it last ran, then exec_start is a clock_task from
another cpu. If
Hi Morten, Peter, Alex,
In a similar context, I noticed that /proc/loadavg makes use of
avenrun[] array which keeps track of the history of the global
load average. This however makes use of the sum of
nr_running + nr_uninterruptible per cpu. Why are we not
using the cpu_load[] array here which
Hi Morten, Peter, Alex,
In a similar context, I noticed that /proc/loadavg makes use of
avenrun[] array which keeps track of the history of the global
load average. This however makes use of the sum of
nr_running + nr_uninterruptible per cpu. Why are we not
using the cpu_load[] array here which
Hi Rik, Mike
On Fri, May 2, 2014 at 12:00 PM, Rik van Riel wrote:
> On 05/02/2014 02:13 AM, Mike Galbraith wrote:
>> On Fri, 2014-05-02 at 00:42 -0400, Rik van Riel wrote:
>>
>>> Whether or not this is the right thing to do remains to be seen,
>>> but it does allow us to verify whether or not
Hi Rik, Mike
On Fri, May 2, 2014 at 12:00 PM, Rik van Riel r...@redhat.com wrote:
On 05/02/2014 02:13 AM, Mike Galbraith wrote:
On Fri, 2014-05-02 at 00:42 -0400, Rik van Riel wrote:
Whether or not this is the right thing to do remains to be seen,
but it does allow us to verify whether or
Hi Jason, Peter,
The below patch looks good to me except for one point.
In idle_balance() the below code snippet does not look right:
- if (pulled_task || time_after(jiffies, this_rq->next_balance)) {
- /*
- * We are going idle. next_balance may be set based on
- * a busy processor. So reset
Hi Jason, Peter,
The below patch looks good to me except for one point.
In idle_balance() the below code snippet does not look right:
- if (pulled_task || time_after(jiffies, this_rq-next_balance)) {
- /*
- * We are going idle. next_balance may be set based on
- * a busy processor. So reset
Hi Viresh,
On Wed, Apr 23, 2014 at 3:08 PM, Viresh Kumar wrote:
> Hi,
>
> File: hrtimer.c
> Function: hrtimer_get_next_event()
>
> I was looking closely at what's waking up my system and
> found this piece of code:
>
> ktime_t hrtimer_get_next_event(void)
> {
> if
Hi Viresh,
On Wed, Apr 23, 2014 at 3:08 PM, Viresh Kumar viresh.ku...@linaro.org wrote:
Hi,
File: hrtimer.c
Function: hrtimer_get_next_event()
I was looking closely at what's waking up my system and
found this piece of code:
ktime_t hrtimer_get_next_event(void)
{
if
Hi Viresh,
I am not too sure about the complexity or the worthiness of this patch but
just wanted to add that care must be taken to migrate the tick_sched_timer
of all the remote CPUs off a hotplugged out CPU if the latter was keeping
their time thus far. In the normal scenario I am guessing the
Hi Viresh,
I am not too sure about the complexity or the worthiness of this patch but
just wanted to add that care must be taken to migrate the tick_sched_timer
of all the remote CPUs off a hotplugged out CPU if the latter was keeping
their time thus far. In the normal scenario I am guessing the
Hi Zoran,
I understand that this approach is non-intrusive with the
running workload.
However it would be nice to know how my system is behaving
in terms of power efficiency at a given instance of time and
accordingly I can take action to kill a few applications to save
power, as against knowing
Hi Zoran,
I understand that this approach is non-intrusive with the
running workload.
However it would be nice to know how my system is behaving
in terms of power efficiency at a given instance of time and
accordingly I can take action to kill a few applications to save
power, as against knowing
Hi Hidetoshi,
The patch looks good to me except the comments around the monotonicity
of the return value of the idle stats observer. I am unable to relate them
to the dependency on nr_iowait_cpu.
I see that when the reader queries for the idle stats and calls
get_cpu_idle_time_us(), the
Hi Hidetoshi,
The patch looks good to me except the comments around the monotonicity
of the return value of the idle stats observer. I am unable to relate them
to the dependency on nr_iowait_cpu.
I see that when the reader queries for the idle stats and calls
get_cpu_idle_time_us(), the
On Sat, Mar 15, 2014 at 3:45 AM, Kirill Tkhai wrote:
> This reverts commit 4c6c4e38c4e9 [sched/core: Fix endless loop in
> pick_next_task()], which is not necessary after [sched/rt: Substract number
> of tasks of throttled queues from rq->nr_running]
Reviewed-by: Preeti U Murthy
>
>
On Sat, Mar 15, 2014 at 3:45 AM, Kirill Tkhai tk...@yandex.ru wrote:
This reverts commit 4c6c4e38c4e9 [sched/core: Fix endless loop in
pick_next_task()], which is not necessary after [sched/rt: Substract number
of tasks of throttled queues from rq-nr_running]
Reviewed-by: Preeti U Murthy
On Sat, Mar 15, 2014 at 3:44 AM, Kirill Tkhai wrote:
> {inc,dec}_rt_tasks used to count entities which are directly queued
> on rt_rq. If an entity was not a task (i.e., it is some queue), its
> children were not counted.
Its always the case that a task is queued right, never a sched entity?
On Sat, Mar 15, 2014 at 3:44 AM, Kirill Tkhai tk...@yandex.ru wrote:
{inc,dec}_rt_tasks used to count entities which are directly queued
on rt_rq. If an entity was not a task (i.e., it is some queue), its
children were not counted.
Its always the case that a task is queued right, never a sched
Hi Thomas,
With regard to the patch: "tick: Clear broadcast pending bit when
switching to oneshot"
isn't BROADCAST_EXIT called atleast after initializing the high
resolution timers while
handling the broadcast IPI and before re-entering idle? This should
clear the cpu bit
in the pending mask
Hi Thomas,
With regard to the patch: tick: Clear broadcast pending bit when
switching to oneshot
isn't BROADCAST_EXIT called atleast after initializing the high
resolution timers while
handling the broadcast IPI and before re-entering idle? This should
clear the cpu bit
in the pending mask right?
Hi Daniel,
On Fri, Feb 7, 2014 at 4:40 AM, Daniel Lezcano
wrote:
> The idle_balance modifies the idle_stamp field of the rq, making this
> information to be shared across core.c and fair.c. As we can know if the
> cpu is going to idle or not with the previous patch, let's encapsulate the
>
HI Daniel,
Isn't the only scenario where another cpu can put an idle task on
our runqueue, in nohz_idle_balance() where only the cpus in
the nohz.idle_cpus_mask are iterated through. But for the case
that this patch is addressing, the cpu in question is not yet a part
of the nohz.idle_cpus_mask
Hi Yijing,
For the powerpc part:
Acked-by: Preeti U Murthy
On Mon, Feb 10, 2014 at 7:28 AM, Yijing Wang wrote:
> Currently, clocksource_register() and __clocksource_register_scale()
> functions always return 0, it's pointless, make functions void.
> And remove the dead code that check the
Hi Yijing,
For the powerpc part:
Acked-by: Preeti U Murthy pre...@linux.vnet.ibm.com
On Mon, Feb 10, 2014 at 7:28 AM, Yijing Wang wangyij...@huawei.com wrote:
Currently, clocksource_register() and __clocksource_register_scale()
functions always return 0, it's pointless, make functions void.
HI Daniel,
Isn't the only scenario where another cpu can put an idle task on
our runqueue, in nohz_idle_balance() where only the cpus in
the nohz.idle_cpus_mask are iterated through. But for the case
that this patch is addressing, the cpu in question is not yet a part
of the nohz.idle_cpus_mask
Hi Daniel,
On Fri, Feb 7, 2014 at 4:40 AM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
The idle_balance modifies the idle_stamp field of the rq, making this
information to be shared across core.c and fair.c. As we can know if the
cpu is going to idle or not with the previous patch, let's
Hi,
On Thu, Jan 30, 2014 at 10:55 PM, Daniel Lezcano
wrote:
> On 01/30/2014 05:35 PM, Peter Zijlstra wrote:
>>
>> On Thu, Jan 30, 2014 at 05:27:54PM +0100, Daniel Lezcano wrote:
>>>
>>> struct cpuidle_state *state = >states[rq->index];
>>>
>>> And from the state, we have the following
Hi,
On Thu, Jan 30, 2014 at 10:55 PM, Daniel Lezcano
daniel.lezc...@linaro.org wrote:
On 01/30/2014 05:35 PM, Peter Zijlstra wrote:
On Thu, Jan 30, 2014 at 05:27:54PM +0100, Daniel Lezcano wrote:
struct cpuidle_state *state = drv-states[rq-index];
And from the state, we have the following
Hi Paul,
The commit id:e1d690cdc07637131ba4334: timers: Track total number of
timers in list has
a minor glitch in the changelog.
I am referring to your
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
rcu/timers branch.
"even if ->active_timers is zero, there might well be
Hi Paul,
The commit id:e1d690cdc07637131ba4334: timers: Track total number of
timers in list has
a minor glitch in the changelog.
I am referring to your
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
rcu/timers branch.
even if -active_timers is zero, there might well be
Hi,
On Thu, Jan 23, 2014 at 11:22 AM, Viresh Kumar wrote:
> Hi Guys,
>
> So the first question is why cpufreq needs it and is it really stupid?
> Yes, it is stupid but that's how its implemented since a long time. It does
> so to get data about the load on CPUs, so that freq can be scaled
Hi,
On Thu, Jan 23, 2014 at 11:22 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
Hi Guys,
So the first question is why cpufreq needs it and is it really stupid?
Yes, it is stupid but that's how its implemented since a long time. It does
so to get data about the load on CPUs, so that freq
Hi,
On Mon, Jan 6, 2014 at 5:09 PM, Mel Gorman wrote:
> (Rik, you authored this patch so it should be sent from you and needs a
> signed-off assuming people are ok with the changelog.)
>
> Thomas Hellstrom bisected a regression where erratic 3D performance is
> experienced on virtual machines as
Hi,
On Mon, Jan 6, 2014 at 5:09 PM, Mel Gorman mgor...@suse.de wrote:
(Rik, you authored this patch so it should be sent from you and needs a
signed-off assuming people are ok with the changelog.)
Thomas Hellstrom bisected a regression where erratic 3D performance is
experienced on virtual
Hi all,
The code looks correct and inviting to me as it has led to good cleanups.
I dont think passing 0 as the argument to the function
sched_clock_idle_wakeup_event()
should lead to problems,as it does not do anything useful with the
passed arguments.
My only curiosity is what was the purpose
Hi all,
The code looks correct and inviting to me as it has led to good cleanups.
I dont think passing 0 as the argument to the function
sched_clock_idle_wakeup_event()
should lead to problems,as it does not do anything useful with the
passed arguments.
My only curiosity is what was the purpose
Hi Alex
I apologise for the delay in replying .
On Wed, Nov 7, 2012 at 6:57 PM, Alex Shi wrote:
> On 11/07/2012 12:37 PM, Preeti Murthy wrote:
>> Hi Alex,
>>
>> What I am concerned about in this patchset as Peter also
>> mentioned in the previous discussion of your ap
Hi Alex
I apologise for the delay in replying .
On Wed, Nov 7, 2012 at 6:57 PM, Alex Shi alex@intel.com wrote:
On 11/07/2012 12:37 PM, Preeti Murthy wrote:
Hi Alex,
What I am concerned about in this patchset as Peter also
mentioned in the previous discussion of your approach
(https
Hi Alex,
What I am concerned about in this patchset as Peter also
mentioned in the previous discussion of your approach
(https://lkml.org/lkml/2012/8/13/139)
is that:
1.Using nr_running of two different sched groups to decide which one
can be group_leader or group_min might not be be the right
Hi Alex,
What I am concerned about in this patchset as Peter also
mentioned in the previous discussion of your approach
(https://lkml.org/lkml/2012/8/13/139)
is that:
1.Using nr_running of two different sched groups to decide which one
can be group_leader or group_min might not be be the right
Hi Paul, Ben,
A few queries regarding this patch:
1.What exactly is the significance of introducing sched_avg structure
for a runqueue? If I have
understood correctly, sched_avg keeps track of how long a task has
been active,
how long has it been serviced by the processor and its
Hi Paul, Ben,
A few queries regarding this patch:
1.What exactly is the significance of introducing sched_avg structure
for a runqueue? If I have
understood correctly, sched_avg keeps track of how long a task has
been active,
how long has it been serviced by the processor and its
The benchmark:
/*
* test.c - Simulate workloads that load the CPU differently
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; version 2 of the License.
*
* This
The benchmark:
/*
* test.c - Simulate workloads that load the CPU differently
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; version 2 of the License.
*
* This
68 matches
Mail list logo
