* Christoph Lameter <[email protected]> wrote:
> On a 8p system:
>
> I) Percent of ticks where load balancing was found to be required
>
> II) Percent of ticks where we attempted load balancing
> but we found that we need to try again due to load balancing
> in progress elsewhere (This increases (I) since we found that
> load balancing was required but we decided to defer. Tasklet
> was not invoked).
>
> I) II)
> Boot: 70% ~1%
> AIM7: 30% 2%
> Idle: 50% <0.5%
>
> 256p:
> I) II)
> Boot: 80% 30%
> AIM7: 90% 30%
> Idle: 95% 30%
nice measurements and interesting results.
note that with a tasklet a 'retry' will often be done on the /same/ CPU
that was running the tasklet when we tried to schedule it. I.e. such a
'collision' will result not only in the 'loss' of the local rebalance
event, but also causes /another/ rebalance event on the remote CPU.
so a better model would be the trylock model i suggested in the previous
mail: to just lose the rebalance events upon collision and not cause
extra work on the remote CPU. I'd also suggest to keep the rebalancing
code under the irqs-off section, like it is currently - only do it
conditional on trylock success. Do you think that would work?
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
