![]() | |||||||||||||
Messages in this thread |
Jesse Barnes wrote: > On Saturday, July 24, 2004 1:26 am, Nick Piggin wrote: > >>You might have the theoretical problem of ending up with more than >>one disjoint top level domain (ie. no overlap, basically partitioning >>the CPUs). > > > Yes, we'll have several disjoint per-node cpu spans for a large system, but > nearby nodes *will* overlap with more distant nodes than any given node, so I > think we're covered, unless I'm misunderstanding something. > No, I'm sure you are covered. The situation I thought of would be something like the following: CPUs 0-63, all within distance 4 --- gap distance 5 --- CPUs 64-127. Where you wouldn't have any overlap between the two sets of CPUs. This is probably not applicable to you though. > >>No doubt you could come up with something provably correct, however >>it might just be good enough to examine the end result and check that >>it is good. At least while you test different configurations. > > > Right. And ultimately, I think we'll want the hierarchy I mentioned in the > comments, that'll cover us a little better I think. > Yeah I would agree. No doubt you could spend a long time on improving it. Start simple so you have a baseline of course. If you're going to be looking at this, take a look at the way we're building domains in the "[PATCH] consolidate sched domains" patch I posted the other day. It may simplify your job as well, for example if you can make use of the init_sched_build_groups function. - 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/ | ||||||||||||
| Last update: 2005-03-22 14:04 [from the cache] ©2003-2008 | |||||||||||||