Re: [patch] scheduler: rebalance_tick interval update

[Darren Hart <darren@dvhart.com>]

On Tue, 2004-11-16 at 07:56 -0800, Darren Hart wrote:
> > >This example didn't take into account:
> > >	unsigned long j = jiffies + CPU_OFFSET(this_cpu);
> > >Which, even if the last_balance's were equal and intervals were the same
> > >(unlikely since each CPU has it's own domain and the intervals are
> > >adjusted independently?),
> > >
> > 
> > That is correct.
> > 
> > > would prevent them from both running on the
> > >same timer tick.  So I don't think this example is accurate.  On the
> > >other hand, even if it was valid, I would prefer this to running the
> > >load_balance code on the same CPU and domain several ticks in a row
> > >(which obviously accomplishes nothing).
> > >
> > 
> > It is valid because the CPU_OFFSET basically just adds a constant amount
> > to each CPU's 'jiffies'. My example took that into account already and
> > used the absolute jiffies value. If that doesn't convince you, pretend
> > that the delay were to occur to CPU0, whos CPU_OFFSET == 0.
> 
> 
> Heh, I thought of exactly that case when I rolled out of bed this
> morning.  Funny how that happens sometimes, you can be sitting in front
> of the code and make what you think is a perfectly valid analysis and
> then wake up the next morning with no context at all and realize you
> were wrong.  That happens to me anyway :-), I can't be the only one...
> 
> Nevertheless, that is a pretty unlikely corner case.  They double up
> only when last_balance+interval is the same and one of the CPUs involved
> is CPU 0.
> 


Hey Nick,

I haven't heard anything on this thread in a couple of days, do you
agree we should me the change?  I feel there are legitimate reasons to
use =jiffies instead of +=interval for the ->last_balanced assignment.
I have already elaborated on these and provided counter arguments to the
ones you posted that I think make a strong case.  If you still oppose
the change, what would I need to provide to convince you?


-- 
Darren Hart <darren@dvhart.com>