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 forgetti
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
>> > re
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 ma
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 th
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 se
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 pre
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 e
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 ze
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 w
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 t
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 the
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,
13 matches
Mail list logo
