* Tong Li <[EMAIL PROTECTED]> wrote: > Thanks for the patch. It doesn't work well on my 8-way box. Here's the > output at two different times. It's also changing all the time.
you need to measure it over longer periods of time. Its not worth balancing for such a thing in any high-frequency manner. (we'd trash the cache constantly migrating tasks back and forth.) > [time 2] > 3721 tongli 20 0 7864 108 16 R 91 0.0 1:44.67 loop > 3720 tongli 20 0 7864 108 16 R 89 0.0 1:40.55 loop > 3722 tongli 20 0 7864 108 16 R 86 0.0 1:41.40 loop > 3723 tongli 20 0 7864 108 16 R 82 0.0 1:38.94 loop > 3715 tongli 20 0 7864 108 16 R 82 0.0 1:43.09 loop > 3717 tongli 20 0 7864 108 16 R 79 0.0 1:46.38 loop > 3718 tongli 20 0 7864 108 16 R 79 0.0 1:40.72 loop > 3714 tongli 20 0 7864 108 16 R 77 0.0 1:40.17 loop > 3719 tongli 20 0 7864 108 16 R 73 0.0 1:35.41 loop > 3716 tongli 20 0 7864 108 16 R 61 0.0 1:38.66 loop the runtime ranges from 1:38.66 to 1:46.38 - that's a +-3% spread which is pretty acceptable for ~90 seconds of runtime. Note that the percentages you see above were likely done over a shorter period that's why you see them range from 61% to 91%. > I'm running 2.6.23-rc1 with your patch on a two-socket quad-core > system. Top refresh rate is the default 3s. the 3s is the problem: change that to 60s! We no way want to over-migrate for SMP fairness, the change i did gives us reasonable long-term SMP fairness without the need for high-rate rebalancing. 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/