Messages in this thread | | | From | "John Hawkes" <> | Subject | Re: boot-time slowdown for measure_migration_cost | Date | Mon, 30 Jan 2006 12:43:22 -0800 |
| |
From: "Luck, Tony" <tony.luck@intel.com> ... > So the variation in the computed value of migration_cost was at worst > 2% with these modifications to the algorithm. Do you really need to know > the value to this accuracy? What 2nd order bad effects would occur from > using an off-by-2% value for scheduling decisions? > > On the plus side Prarit's results show that this time isn't scaling with > NR_CPUS ... apparently just cache size and number of domains are significant > in the time to compute.
Yes, the calculation is done just once per domain level, and a desire to achieve great accuracy for the calculation presupposes that the cpuM-to-cpuN migration cost for a given domain level is identical (or very close) across all the CPU pairs. That is, for a given domain level, only one CPU pair are chosen for the calculation. For the ia64/sn2 NUMA Altix, and I suspect for other NUMA platforms, this just isn't true for the middle domain level (i.e., the level that appears when the CPU count is >32p) -- i.e., some CPU pairs are "closer" than other pairs. The variation for other CPU pairs in this domain level is certainly much greater than 2%.
John Hawkes
- 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/
| |