Re: weakness of runnable load tracking?

2012-12-08 Thread Alex Shi
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

Re: weakness of runnable load tracking?

2012-12-06 Thread Alex Shi
> > 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;

Re: weakness of runnable load tracking?

2012-12-06 Thread Alex Shi
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

Re: weakness of runnable load tracking?

2012-12-06 Thread Alex Shi
>> 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

Re: weakness of runnable load tracking?

2012-12-06 Thread Paul Turner
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

Re: weakness of runnable load tracking?

2012-12-06 Thread Mike Galbraith
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

Re: weakness of runnable load tracking?

2012-12-06 Thread Alex Shi
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

Re: weakness of runnable load tracking?

2012-12-06 Thread Alex Shi
>> >> 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

Re: weakness of runnable load tracking?

2012-12-05 Thread Preeti U Murthy
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

Re: weakness of runnable load tracking?

2012-12-05 Thread Mike Galbraith
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

Re: weakness of runnable load tracking?

2012-12-05 Thread Alex Shi
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 >