Hi all
Not pushing this for mainline because this is not the "right way" to do it,
but it works here and now for those who have P4HT processors.
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.
This patch (together with the ht base patch) will not allow a priority >10
difference to run concurrently on both siblings, instead putting the low
priority one to sleep. Overall if you run concurrent nice 0 and nice 20 tasks
with this patch your cpu throughput will drop during heavy periods by up to
10% (the hyperthread benefit), but your nice 0 task will run about 90%
faster. It has no effect if you don't run any tasks at different "nice"
levels. It does not modify real time tasks or kernel threads, and will allow
niced tasks to run while a high priority kernel thread is running on the
sibling cpu.
http://ck.kolivas.org/patches/2.6/2.6.1/experimental/
There are other patches that go with it which is why these have slight offsets
but should work ok.
Con
On Thursday 29 Jan 2004 09:17, Con Kolivas wrote:
> Hi all
>
> This patch (together with the ht base patch) will not allow a priority >10
> difference to run concurrently on both siblings, instead putting the low
> priority one to sleep. Overall if you run concurrent nice 0 and nice 20
> tasks with this patch your cpu throughput will drop during heavy periods by
> up to 10% (the hyperthread benefit), but your nice 0 task will run about
> 90% faster. It has no effect if you don't run any tasks at different "nice"
> levels. It does not modify real time tasks or kernel threads, and will
> allow niced tasks to run while a high priority kernel thread is running on
> the sibling cpu.
If I read you correctly, if one thread has nothing else to do but the nice 0
task, the nice 20 task will never be scheduled at all ? Sounds like not the
perfect solution to me...
Jos
On Thu, 29 Jan 2004 21:28, Con Kolivas wrote:
> On Thu, 29 Jan 2004 20:39, Jos Hulzink wrote:
> > On Thursday 29 Jan 2004 09:17, Con Kolivas wrote:
> > > Hi all
> > >
> > > This patch (together with the ht base patch) will not allow a priority
> > >
> > > >10 difference to run concurrently on both siblings, instead putting
> > > > the
> > >
> > > low priority one to sleep. Overall if you run concurrent nice 0 and
> > > nice 20 tasks with this patch your cpu throughput will drop during
> > > heavy periods by up to 10% (the hyperthread benefit), but your nice 0
> > > task will run about 90% faster. It has no effect if you don't run any
> > > tasks at different "nice" levels. It does not modify real time tasks or
> > > kernel threads, and will allow niced tasks to run while a high priority
> > > kernel thread is running on the sibling cpu.
> >
> > If I read you correctly, if one thread has nothing else to do but the
> > nice 0 task, the nice 20 task will never be scheduled at all ? Sounds
> > like not the perfect solution to me...
>
> Wrong.. there is the matter of the other runqueue in smp mode :)
Oops I should have been clearer than that. Shouldn't email in a hurry. Yes the
solution is not the right one, yes you can get longer periods of starvation
compared with UP mode, but if the constant bouncing and balancing of tasks
puts the low priority task on the same runqueue as the high priority one it
will get scheduled. This is why Nick's idea of unbalancing runqueues for
priority difference makes sense. However pushing and pulling tasks very
frequently may be expensive so it's hard to know how well that will work.
Con
On Thu, 29 Jan 2004 20:39, Jos Hulzink wrote:
> On Thursday 29 Jan 2004 09:17, Con Kolivas wrote:
> > Hi all
> >
> > This patch (together with the ht base patch) will not allow a priority
> > >10 difference to run concurrently on both siblings, instead putting the
> > low priority one to sleep. Overall if you run concurrent nice 0 and nice
> > 20 tasks with this patch your cpu throughput will drop during heavy
> > periods by up to 10% (the hyperthread benefit), but your nice 0 task will
> > run about 90% faster. It has no effect if you don't run any tasks at
> > different "nice" levels. It does not modify real time tasks or kernel
> > threads, and will allow niced tasks to run while a high priority kernel
> > thread is running on the sibling cpu.
>
> If I read you correctly, if one thread has nothing else to do but the nice
> 0 task, the nice 20 task will never be scheduled at all ? Sounds like not
> the perfect solution to me...
Wrong.. there is the matter of the other runqueue in smp mode :)
Con