* Chen, Kenneth W <[EMAIL PROTECTED]> wrote: > Ingo Molnar wrote on Sunday, April 03, 2005 7:30 AM > > how close are these numbers to the real worst-case migration costs on > > that box? > > I booted your latest patch on a 4-way SMP box (1.5 GHz, 9MB ia64). This > is what it produces. I think the estimate is excellent. > > [00]: - 10.4(0) 10.4(0) 10.4(0) > [01]: 10.4(0) - 10.4(0) 10.4(0) > [02]: 10.4(0) 10.4(0) - 10.4(0) > [03]: 10.4(0) 10.4(0) 10.4(0) - > --------------------- > cacheflush times [1]: 10.4 (10448800)
great! How long does the benchmark take (hours?), and is there any way to speed up the benchmarking (without hurting accuracy), so that multiple migration-cost settings could be tried? Would it be possible to try a few other values via the migration_factor boot option, in 0.5 msec steps or so, to find the current sweet spot? It used to be at 11 msec previously, correct? E.g. migration_factor=105 will change the cost to 10.9 msec, migration_factor=110 will change it to 11.4, etc. Or with the latest snapshot you can set absolute values as well, migration_cost=11500 sets the cost to 11.5 msec. > One other minor thing: when booting a numa kernel on smp box, there is > a numa scheduler domain at the top level and cache_hot_time will be > set to 0 in that case on smp box. Though this will be a mutt point > with recent patch from Suresh Siddha for removing the extra bogus > scheduler domains. > http://marc.theaimsgroup.com/?t=111240208000001&r=1&w=2 at first sight the dummy domain should not be a problem, the ->cache_hot values are only used when deciding whether a task should migrate to a parallel domain or not - if there's an extra highlevel domain instance then such decisions are never made, so a zero value makes no difference. 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/
