Following on from the previous hyperthread smart nice patch;

>A while back we had an lkml thread about the problem of running low priority 
>tasks on hyperthread enabled cpus in SMP mode. Brief summary: If you run a 
>P4HT in uniprocessor mode and run a cpu intensive task at nice +20 (like 
>setiathome), the most cpu it will get during periods of heavy usage is about 
>8%. If you boot a P4HT in SMP mode and run a cpu intensive task at nice +20 
>then if you run a task even at nice -20 concurrently, the nice +20 task will 
>get 50% of the cpu time even though you have a very high priority task. So 
>ironically booting in SMP mode makes your machine slower for running 
>background tasks.

Criticism was laid at the previous patch for the way a more "nice" task might 
never run on the sibling cpu if a high priority task was running. This patch 
is a much better solution.

What this one does is the following; If there is a "nice" difference between 
tasks running on logical cores of the same cpu, the more "nice" one will run 
a proportion of time equal to the timeslice it would have been given relative 
to the less "nice" task. 
ie a nice 19 task running on one core and the nice 0 task running on the other 
core will let the nice 0 task run continuously (102ms is normal timeslice) 
and the nice 19 task will only run for the last 10ms of time the nice 0 task 
is running. This makes for a much more balanced resource distribution, gives 
significant preference to the higher priority task, but allows them to 
benefit from running on both logical cores.

This seems to me a satisfactory solution to the hyperthread vs nice problem. 
Once again this is too arch. specific a change to sched.c for mainline, but 
as proof of concept I believe it works well for those who need something that 
works that they can use now.

http://ck.kolivas.org/patches/2.6/2.6.1/experimental/

The stuff on my website is incremental with my other experiments, but the 
attached patch applies cleanly to 2.6.1

Con