* Paul Jackson <[email protected]> wrote:
> Nick wrote:
> > In a sense, the information *is* already there - in node_distance.
> > What I think should be done is probably to use node_distance when
> > calculating costs, ...
>
> Hmmm ... perhaps I'm confused, but this sure sounds like the alternative
> implementation of cpu_distance using node_distance that I submitted to
> this thread about 16 hours ago.
yes, it's that method.
> [...] It was using this alternative that got me the more varied
> matrix:
>
> ---------------------
> [00] [01] [02] [03] [04] [05] [06] [07]
> [00]: - 4.0(0) 21.7(1) 21.7(1) 25.2(2) 25.2(2) 25.3(3) 25.3(3)
> [01]: 4.0(0) - 21.7(1) 21.7(1) 25.2(2) 25.2(2) 25.3(3) 25.3(3)
> [02]: 21.7(1) 21.7(1) - 4.0(0) 25.3(3) 25.3(3) 25.2(2) 25.2(2)
> [03]: 21.7(1) 21.7(1) 4.0(0) - 25.3(3) 25.3(3) 25.2(2) 25.2(2)
> [04]: 25.2(2) 25.2(2) 25.3(3) 25.3(3) - 4.0(0) 21.7(1) 21.7(1)
> [05]: 25.2(2) 25.2(2) 25.3(3) 25.3(3) 4.0(0) - 21.7(1) 21.7(1)
> [06]: 25.3(3) 25.3(3) 25.2(2) 25.2(2) 21.7(1) 21.7(1) - 4.0(0)
> [07]: 25.3(3) 25.3(3) 25.2(2) 25.2(2) 21.7(1) 21.7(1) 4.0(0) -
> ---------------------
the problem i mentioned earlier is that there is no other use for the
matrix right now than the domain hierarchy. And if there's no place in
the domain hieararchy to put this info then the information is lost.
so we might be able to _measure_ a rank-3 matrix, but if the domain is
only rank-2 then we'll have to discard one level of information.
we could try some hybride method of averaging 25.3 with 21.7 and putting
that into the domain tree, but i'd be against it for the following
reasons:
firstly, _if_ an extra level in the hierarchy makes a difference, we
might as well add it to the domain tree - and that may bring other
advantages (in terms of more finegrained balancing) in addition to
better migration.
secondly, right now the cost measurement method and calculation is
rather simple and has minimal assumptions, and i'd like to keep it so as
long as possible. If an extra domain level gives problems or artifacts
elsewhere then we should fix those problems if possible, and not
complicate the cost calculation.
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]
