Hi,
On 03/30/2013 07:34 PM, Alex Shi wrote:
> On 03/30/2013 07:25 PM, Preeti U Murthy wrote:
I still give the rq->util weight even the nr_running is 0, because some
transitory tasks may actived on the cpu, but just missed on balancing
point.
I just wondering that
On 03/30/2013 07:25 PM, Preeti U Murthy wrote:
>> > I still give the rq->util weight even the nr_running is 0, because some
>> > transitory tasks may actived on the cpu, but just missed on balancing
>> > point.
>> >
>> > I just wondering that forgetting rq->util when nr_running = 0 is the
>> >
On 03/29/2013 07:09 PM, Alex Shi wrote:
> On 03/29/2013 08:42 PM, Preeti U Murthy wrote:
did you try the simplest benchmark: while true; do :; done
>> Yeah I tried out this while true; do :; done benchmark on a vm which ran
>
> Thanks a lot for trying!
>
> What's do you mean 'vm'? Virtual
On 03/29/2013 07:09 PM, Alex Shi wrote:
On 03/29/2013 08:42 PM, Preeti U Murthy wrote:
did you try the simplest benchmark: while true; do :; done
Yeah I tried out this while true; do :; done benchmark on a vm which ran
Thanks a lot for trying!
What's do you mean 'vm'? Virtual machine?
On 03/30/2013 07:25 PM, Preeti U Murthy wrote:
I still give the rq-util weight even the nr_running is 0, because some
transitory tasks may actived on the cpu, but just missed on balancing
point.
I just wondering that forgetting rq-util when nr_running = 0 is the
real root cause if
Hi,
On 03/30/2013 07:34 PM, Alex Shi wrote:
On 03/30/2013 07:25 PM, Preeti U Murthy wrote:
I still give the rq-util weight even the nr_running is 0, because some
transitory tasks may actived on the cpu, but just missed on balancing
point.
I just wondering that forgetting rq-util when
On 03/29/2013 08:42 PM, Preeti U Murthy wrote:
>> > did you try the simplest benchmark: while true; do :; done
> Yeah I tried out this while true; do :; done benchmark on a vm which ran
Thanks a lot for trying!
What's do you mean 'vm'? Virtual machine?
> on 2 socket, 2 cores each socket and 2
Hi Alex,
On 03/25/2013 10:22 AM, Alex Shi wrote:
> On 03/22/2013 01:14 PM, Preeti U Murthy wrote:
the value get from decay_load():
sa->runnable_avg_sum = decay_load(sa->runnable_avg_sum,
in decay_load it is possible to be set zero.
>> Yes you are right, it is possible to be
Hi Alex,
On 03/25/2013 10:22 AM, Alex Shi wrote:
On 03/22/2013 01:14 PM, Preeti U Murthy wrote:
the value get from decay_load():
sa-runnable_avg_sum = decay_load(sa-runnable_avg_sum,
in decay_load it is possible to be set zero.
Yes you are right, it is possible to be set to 0, but after a
On 03/29/2013 08:42 PM, Preeti U Murthy wrote:
did you try the simplest benchmark: while true; do :; done
Yeah I tried out this while true; do :; done benchmark on a vm which ran
Thanks a lot for trying!
What's do you mean 'vm'? Virtual machine?
on 2 socket, 2 cores each socket and 2
On 03/22/2013 01:14 PM, Preeti U Murthy wrote:
>> >
>> > the value get from decay_load():
>> > sa->runnable_avg_sum = decay_load(sa->runnable_avg_sum,
>> > in decay_load it is possible to be set zero.
> Yes you are right, it is possible to be set to 0, but after a very long
> time, to be more
On 03/22/2013 01:14 PM, Preeti U Murthy wrote:
the value get from decay_load():
sa-runnable_avg_sum = decay_load(sa-runnable_avg_sum,
in decay_load it is possible to be set zero.
Yes you are right, it is possible to be set to 0, but after a very long
time, to be more precise, nearly 2
Hi,
On 03/22/2013 07:00 AM, Alex Shi wrote:
> On 03/21/2013 06:27 PM, Preeti U Murthy wrote:
did you close all of background system services?
In theory the rq->avg.runnable_avg_sum should be zero if there is no
task a bit long, otherwise there are some bugs in kernel.
>> Could you
On 03/21/2013 06:27 PM, Preeti U Murthy wrote:
>> > did you close all of background system services?
>> > In theory the rq->avg.runnable_avg_sum should be zero if there is no
>> > task a bit long, otherwise there are some bugs in kernel.
> Could you explain why rq->avg.runnable_avg_sum should be
On 03/21/2013 02:57 PM, Alex Shi wrote:
> On 03/21/2013 04:41 PM, Preeti U Murthy wrote:
>> Yes, I did find this behaviour on a 2 socket, 8 core machine very
>> consistently.
>>
>> rq->util cannot go to 0, after it has begun accumulating load right?
>>
>> Say a load was running on a runqueue
On 03/21/2013 04:41 PM, Preeti U Murthy wrote:
>> >
> Yes, I did find this behaviour on a 2 socket, 8 core machine very
> consistently.
>
> rq->util cannot go to 0, after it has begun accumulating load right?
>
> Say a load was running on a runqueue which had its rq->util to be at
> 100%. After
Hi Alex,
On 03/21/2013 01:13 PM, Alex Shi wrote:
> On 03/20/2013 12:57 PM, Preeti U Murthy wrote:
>> Neither core will be able to pull the task from the other to consolidate
>> the load because the rq->util of t2 and t4, on which no process is
>> running, continue to show some number even though
On 03/20/2013 12:57 PM, Preeti U Murthy wrote:
> Neither core will be able to pull the task from the other to consolidate
> the load because the rq->util of t2 and t4, on which no process is
> running, continue to show some number even though they degrade with time
> and sgs->utils accounts for
On 03/20/2013 12:57 PM, Preeti U Murthy wrote:
Neither core will be able to pull the task from the other to consolidate
the load because the rq-util of t2 and t4, on which no process is
running, continue to show some number even though they degrade with time
and sgs-utils accounts for them.
Hi Alex,
On 03/21/2013 01:13 PM, Alex Shi wrote:
On 03/20/2013 12:57 PM, Preeti U Murthy wrote:
Neither core will be able to pull the task from the other to consolidate
the load because the rq-util of t2 and t4, on which no process is
running, continue to show some number even though they
On 03/21/2013 04:41 PM, Preeti U Murthy wrote:
Yes, I did find this behaviour on a 2 socket, 8 core machine very
consistently.
rq-util cannot go to 0, after it has begun accumulating load right?
Say a load was running on a runqueue which had its rq-util to be at
100%. After the load
On 03/21/2013 02:57 PM, Alex Shi wrote:
On 03/21/2013 04:41 PM, Preeti U Murthy wrote:
Yes, I did find this behaviour on a 2 socket, 8 core machine very
consistently.
rq-util cannot go to 0, after it has begun accumulating load right?
Say a load was running on a runqueue which had its
On 03/21/2013 06:27 PM, Preeti U Murthy wrote:
did you close all of background system services?
In theory the rq-avg.runnable_avg_sum should be zero if there is no
task a bit long, otherwise there are some bugs in kernel.
Could you explain why rq-avg.runnable_avg_sum should be zero? What if
Hi,
On 03/22/2013 07:00 AM, Alex Shi wrote:
On 03/21/2013 06:27 PM, Preeti U Murthy wrote:
did you close all of background system services?
In theory the rq-avg.runnable_avg_sum should be zero if there is no
task a bit long, otherwise there are some bugs in kernel.
Could you explain why
Hi Alex,
Please note one point below.
On 02/18/2013 10:37 AM, Alex Shi wrote:
> This patch enabled the power aware consideration in load balance.
>
> As mentioned in the power aware scheduler proposal, Power aware
> scheduling has 2 assumptions:
> 1, race to idle is helpful for power saving
>
Hi Alex,
Please note one point below.
On 02/18/2013 10:37 AM, Alex Shi wrote:
This patch enabled the power aware consideration in load balance.
As mentioned in the power aware scheduler proposal, Power aware
scheduling has 2 assumptions:
1, race to idle is helpful for power saving
2, less
This patch enabled the power aware consideration in load balance.
As mentioned in the power aware scheduler proposal, Power aware
scheduling has 2 assumptions:
1, race to idle is helpful for power saving
2, less active sched_groups will reduce power consumption
The first assumption make
This patch enabled the power aware consideration in load balance.
As mentioned in the power aware scheduler proposal, Power aware
scheduling has 2 assumptions:
1, race to idle is helpful for power saving
2, less active sched_groups will reduce power consumption
The first assumption make
28 matches
Mail list logo
