On Wed, 2014-05-21 at 11:26 -0700, Davidlohr Bueso wrote:
> On Wed, 2014-05-21 at 09:37 -0700, Tim Chen wrote:
> > On Tue, 2014-05-20 at 18:15 -0700, Joe Perches wrote:
> > > On Tue, 2014-05-20 at 14:04 -0700, Tim Chen wrote:
> > > > On Tue, 2014-05-20 at 13:59 -0700, Tim Chen wrote:
> > > > > On Tue, 2014-05-20 at 13:51 -0700, Jason Low wrote:
> > > > > > On Tue, May 20, 2014 at 1:17 PM, Tim Chen
> > > > > > <tim.c.c...@linux.intel.com> wrote:
> > > > > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > > []
> > > > > > If we want to do idle load balancing only when it is due for a
> > > > > > balance, shouldn't the above just be "if (time_after(jiffies,
> > > > > > rq->next_balance))"?
> > > > >
> > > > > If rq->next_balance and jiffies are equal, then
> > > > > time_after(jiffies, rq->next_balance) check will be false and
> > > > > you will not do balance. But actually you want to balance
> > > > > for this case so the jiffies+1 was used.
> > > >
> > > > So maybe I should switch the check to
> > > > if (time_before(rq->next_balance, jiffies))
> > >
> > > time_after_eq() or time_is_after_eq_jiffies()
> > >
> > >
> >
> > I prefer time_after_eq to keep the code style consistent with the
> > rest of the code in fair.c.
>
> Should all the code be updated then? We should use the existing
> interfaces if available.
>
BTW, if this code was to be updated,
time_is_before_eq_jiffies(rq->next_balance)
check will be the correct thing to do for the patch. This expands to
time_after_eq(jiffies, rq->next_balance), which is what we want.
So something like:
if (time_is_before_eq_jiffies(rq->next_balance)) {
raw_spin_lock_irq(&rq->lock);
update_rq_clock(rq);
update_idle_cpu_load(rq);
raw_spin_unlock_irq(&rq->lock);
rebalance_domains(rq, CPU_IDLE);
}
But I don't think this change is making the code logic any clearer.
I prefer time_after_eq(jiffies, rq->next_balance), which is more
readable.
Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
