lkml.org 
[lkml]   [2007]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] scheduler: improve SMP fairness in CFS

* Tong Li <tong.n.li@intel.com> 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 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: 2007-07-25 21:27    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site