Re: 2.6.12-rc6-mm1

[Martin J. Bligh]

--Con Kolivas <kernel@xxxxxxxxxxx> wrote (on Sunday, June 12, 2005 09:47:08 +1000):

> On Sun, 12 Jun 2005 09:27, Martin J. Bligh wrote:
>> >> not sure what the benefits of the patch are, 
> 
> I should have answered this. Since we moved to one runqueue per cpu with the 
> current scheduler, 'nice' levels basically fall apart on SMP. Balancing tends 
> to group together all the wrong tasks to have any meaningful 'nice' support 
> where often on a 2 cpu machine if we run 4 tasks, 2 nice 0 and 2 nice 19 we 
> end up with:
> 
> cpu 1: nice 19 + nice 19
> cpu 2: nice 0 + nice 0
> 
> which means each nice 19 task gets half a cpu and each nice 0 task gets half a 
> cpu which is lousy fairness. 
> 
> The smp nice patches should end up with
> cpu 1: nice 0 + nice 19
> cpu 2: nice 0 + nice 19
> 
> so that the nice 0 tasks get 95% of a cpu and nice 19 tasks get 5% of a cpu.
> 
> The patches should balance things as fairly as possible according to nice 
> levels across cpus. As you can see this is clearly a bug in behaviour and has 
> been a showstopper for many trying to move from 2.4.

Oh, right. that makes a lot of sense ... maybe just let it have an error
factor when migrating cross numa nodes (ie not be as strict)? Not sure 
that's really the problem, as I doubt anything in my test is actually 
niced anyway (assuming you're meaning static prio, not dynamic). In that
case, your changes should have no effect, right (from explanation, not
looking at the code ;-))

M.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/