On Mon, 8 Oct 2001, Martin J. Bligh wrote:
> Depending on how much extra latency each hop introduces, it may well
> not be worth adding the complexity of differentiating beyond local vs
> remote? At least at first ...
Well, there's already some code to do that (mm/numa.c), but I'm not sure
how applicable it will be to your arch.
> Do you know how many hops SGI can get, and how much extra latency
> you introduce? I know we're something like 10:1 ratio at the moment
> between local and remote.
I think we're something like 1.5:1, and we have machines with up to 256
nodes at the moment, so there can be quite a few hops in the worst case.
> I guess my main point was that the number of levels was more like constant
> than linear. Maybe for large interconnected switched systems with small
> switches, it's n log n, but in practice I think log n is small enough to be
> considered constant (the number of levels of switches).
Depends on how big your node count gets I guess.
> That's what I was planning on ... we'd need m x n classzones, where m
> was the number of levels, and n the number of nodes. Each search would
> obviously be through m classzones. I'll go poke at the current code some more.
Yeah, classzones is one way to go about this. There are some other simple
ways to do nearest node allocation though, given the current
codebase. I'm still trying to figure out which is the most flexible.
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 15 2001 - 21:00:19 EST