On 12/06/2012 11:10 PM, Alex Shi wrote:
>
>>> Hi Paul & Ingo:
>>>
>>> In a short word of this issue: burst forking/waking tasks have no time
>>> accumulate the load contribute, their runnable load are taken as zero.
>>> that make select_task_rq do a wrong decision on which group is idlest.
>>
>> S
>
> The treatment of a burst wake-up however is a little more interesting.
> There are two reasonable trains of thought one can follow, the first
> is that:
> - If it IS truly bursty you don't really want it factoring into long
> term averages since steady state is not going to include that task;
On 12/06/2012 05:12 PM, Mike Galbraith wrote:
> On Thu, 2012-12-06 at 16:06 +0800, Alex Shi wrote:
Hi Paul & Ingo:
In a short word of this issue: burst forking/waking tasks have no time
accumulate the load contribute, their runnable load are taken as zero.
that make s
>> Hi Paul & Ingo:
>>
>> In a short word of this issue: burst forking/waking tasks have no time
>> accumulate the load contribute, their runnable load are taken as zero.
>> that make select_task_rq do a wrong decision on which group is idlest.
>
> So these aren't strictly comparable; bursting and
On Wed, Dec 5, 2012 at 7:13 PM, Alex Shi wrote:
> On 12/05/2012 11:19 PM, Alex Shi wrote:
>> Hi Paul&Ingo:
>>
>> Runnable load tracking patch set introduce a good way to tracking each
>> entity/rq's running time.
>> But when I try to enable it in load balance, I found burst forking
>> many new tas
On Thu, 2012-12-06 at 16:06 +0800, Alex Shi wrote:
> >>
> >> Hi Paul & Ingo:
> >>
> >> In a short word of this issue: burst forking/waking tasks have no time
> >> accumulate the load contribute, their runnable load are taken as zero.
> >> that make select_task_rq do a wrong decision on which group
On 12/06/2012 02:52 PM, Preeti U Murthy wrote:
> Hi Alex,
>> Hi Paul & Ingo:
>>
>> In a short word of this issue: burst forking/waking tasks have no time
>> accumulate the load contribute, their runnable load are taken as zero.
>
> On performing certain experiments on the way PJT's metric calculat
>>
>> Hi Paul & Ingo:
>>
>> In a short word of this issue: burst forking/waking tasks have no time
>> accumulate the load contribute, their runnable load are taken as zero.
>> that make select_task_rq do a wrong decision on which group is idlest.
>
> As you pointed out above, new tasks can (and im
Hi Alex,
> Hi Paul & Ingo:
>
> In a short word of this issue: burst forking/waking tasks have no time
> accumulate the load contribute, their runnable load are taken as zero.
On performing certain experiments on the way PJT's metric calculates the
load,I observed a few things.Based on these obser
On Thu, 2012-12-06 at 11:13 +0800, Alex Shi wrote:
> On 12/05/2012 11:19 PM, Alex Shi wrote:
> > Hi Paul&Ingo:
> >
> > Runnable load tracking patch set introduce a good way to tracking each
> > entity/rq's running time.
> > But when I try to enable it in load balance, I found burst forking
> > ma
On 12/05/2012 11:19 PM, Alex Shi wrote:
> Hi Paul&Ingo:
>
> Runnable load tracking patch set introduce a good way to tracking each
> entity/rq's running time.
> But when I try to enable it in load balance, I found burst forking
> many new tasks will make just few cpu heavy while other cpu has no
>
11 matches
Mail list logo