On Sat, 2006-05-27 at 10:16 +1000, Peter Williams wrote:Mike Galbraith wrote:On Fri, 2006-05-26 at 23:59 +1000, Peter Williams wrote:AFAIK (but I may be wrong) PI is only used by RT tasks and would need to be extended. It could be argued that extending PI so that it can be used by non RT tasks is a worthwhile endeavour in its own right.Con Kolivas wrote:Isn't this exactly what the PI code is there to handle? Is somethingOn Friday 26 May 2006 14:20, Peter Williams wrote:I wasn't aware that you could detect those conditions. They could be very useful.This patch implements hard CPU rate caps per task as a proportion of aA hard cap of 1/1000 could lead to interesting starvation scenarios where a mutex or semaphore was held by a task that hardly ever got cpu. Same goes to a lesser extent to a 0 soft cap.
single CPU's capacity expressed in parts per thousand.
Here is how I handle idleprio tasks in current -ck:
http://ck.kolivas.org/patches/2.6/pre-releases/2.6.17-rc5/2.6.17-rc5-ck1/patches/track_mutexes-1.patch
tags tasks that are holding a mutex
http://ck.kolivas.org/patches/2.6/pre-releases/2.6.17-rc5/2.6.17-rc5-ck1/patches/sched-idleprio-1.7.patch
is the idleprio policy for staircase.
What it does is runs idleprio tasks as normal tasks when they hold a mutex or are waking up after calling down() (ie holding a semaphore).
more than PI needed?
Hm. Looking around a bit, it appears to me that we're one itty bitty
redefine away from PI being global. No idea if/when that will happen
though.