[lkml]   [2013]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] sched: The removal of idle_balance()
On Mon, 2013-02-18 at 13:43 +0530, Srikar Dronamraju wrote:
> > The cache misses dropped by ~23% and migrations dropped by ~28%. I
> > really believe that the idle_balance() hurts performance, and not just
> > for something like hackbench, but the aggressive nature for migration
> > that idle_balance() causes takes a large hit on a process' cache.
> >
> > Think about it some more, just because we go idle isn't enough reason to
> > pull a runable task over. CPUs go idle all the time, and tasks are woken
> > up all the time. There's no reason that we can't just wait for the sched
> > tick to decide its time to do a bit of balancing. Sure, it would be nice
> > if the idle CPU did the work. But I think that frame of mind was an
> > incorrect notion from back in the early 2000s and does not apply to
> > today's hardware, or perhaps it doesn't apply to the (relatively) new
> > CFS scheduler. If you want aggressive scheduling, make the task rt, and
> > it will do aggressive scheduling.
> >
> How is it that the normal tick based load balancing gets it correctly while
> the idle_balance gets is wrong? Can it because of the different
> cpu_idle_type?

Currently looks to be a fluke in my box, as this performance increase
can't be duplicated elsewhere (yet). But from looking at my traces, it
seems that my box does the idle balance at just the wrong time, and
causes these issues.

-- Steve

 \ /
  Last update: 2013-02-18 17:01    [W:0.120 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site