On Wed, Feb 19, 2014 at 10:12:51AM +0000, Alex Shi wrote:
On 02/19/2014 06:05 PM, Alex Shi wrote:
On 02/18/2014 07:50 PM, Morten Rasmussen wrote:
> > - this_load = target_load(this_cpu); > > + this_load = target_load(this_cpu, bias);
It seems that you now apply the bias to both sides of the comparison. The above should be:
this_load = target_load(this_cpu, 100);to make sense.
It do has some confusing meaning of wake_affine.
My point was just that if you apply the bias on both sides of the comparison it has no effect.
From reduce cpu cache miss point, I understand it prefer the prev cpu, so it make this_cpu load a bit heavier than fact.
But in just the following eff_load computing, it set bit heavier of prev cpu: prev_eff_load = bias, while no bias on this_eff_load. That is a bit confusing. Anyone like to explain this?
Yes, if wake_affine prefer current cpu not prev, I can understand to set wake_idx 0 for nothing bias and heavier prev_eff_load later. But why we prefer this cpu not prev?
My understanding is that we do have a slight preference for this_cpu by biasing the prev_cpu load. We are still comparing load, so if this_load is high we use prev_cpu. But since this_cpu is already interrupted we might as well just start the task there if this_load is equal or less than prev_load. If this_load = 0 it can start running immediately, while it would risk having to wait on the rq if we sent it back to prev_cpu.
AFAIU, we don't consider cache hotness at wakeup. Also, since we looking sibling cores when using wake_affine, the cache impact is probably quite limited. I believe it is much worse being scheduled on a cpu where you have to wait longer to get to run than having to migrate your L1 contents.
Morten