Re: [patch] scheduler: rebalance_tick interval update

[Rick Lindsley]

    Yes, but if you balance n ticks since the last _rebalance_, then things will
    be able to drift. Let's say 2 CPUs, they balance at 10 jiffies intervals,
    5 jiffies apart:

[example deleted]

First, why wasn't the rebalance run when it was supposed to be run?

The answer isn't really all that important.  Regardless of the answer,
if this can happen once, I presume it can happen more than once.  Despite
our best efforts, rebalancing ran in the "wrong timeslot". Aside from the
CPU_OFFSET math, it would seem to me that this inexplicable delay, itself,
introduces enough variance to make any hope of keeping the cpus strictly
unsynchronized (!!) something of a pipe dream.  We start them out of sync, and
know that they'll drift.  We can correct them, but they'll drift again.
Why not just acknowledge that behavior, instead of putting effort into
(unsuccessfully) countering it?

Second, it's of marginal usefulness anyway when you consider that
rebalance_tick() is only called with HZ granularity, except for
unpredictable times from fork().  You're going to be doubling up no matter
what you do once you get more than 16 siblings (see SD_SIBLING_INIT:
busy_factor * max_interval).

Lastly, why do we care?  To turn the question around, were we seeing load
balancing colliding without this attempt at forced spacing?  And if so,
what was the effect (and patterns) of those collisions?  Having a variable
named last_balance which represents when we last *would have liked to
have* balanced seems far less useful than knowing when we really did.

Rick
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/