Re: -mm seems significanty slower than mainline on kernbench

[Con Kolivas <kernel@kolivas.org>]

On Wed, 11 Jan 2006 02:40 pm, Peter Williams wrote:
> Con Kolivas wrote:
> > I disagree. I think the current implementation changes the balancing
> > according to nice much more effectively than previously where by their
> > very nature, low priority tasks were balanced more frequently and ended
> > up getting their own cpu.
>
> I can't follow the logic here 

cpu bound non interactive tasks have long timeslices. Tasks that have short 
timeslices like interactive ones or cpu bound ones at nice 19 have short 
timeslices. If a nice 0 and nice 19 task are running on the same cpu, the 
nice 19 one is going to be spending most of its time waiting in the runqueue. 
As soon as an idle cpu appears it will only pull a task that is waiting in a 
runqueue... and that is going to be the low priority tasks. 

> Yes, that's true.  I must admit that I wouldn't have expected the
> increased overhead to be very big.  In general, the "system" CPU time in
> a kernbench is only about 1% of the total CPU time and the extra
> overhead should be just a fraction of that.

Doesn't appear to be system time. Extra idle time does suggest poor balancing 
though. Remember the effort I went to to avoid altering the delicate idle 
balancing...

> It's possible that better distribution of niceness across CPU leads to
> more preemption within a run queue (i.e. if there all the same priority
> they won't preempt each other much) leading to more context switches.

Can't see how that is for what you say below.

> But you wouldn't expect that to show up in kernbench as the tasks are
> all the same niceness and usually end up with the same dynamic priority.

The whole of userspace on a kernbench run is going to be nice 0. 

Let's wait till we confirm or deny this patch is responsible before 
postulating further.

Cheers,
Con