lkml.org 
[lkml]   [2006]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC 2/5] sched: Add CPU rate soft caps
Con Kolivas wrote:
> On Friday 26 May 2006 14:20, Peter Williams wrote:
>> This patch implements (soft) CPU rate caps per task as a proportion of a
>> single CPU's capacity expressed in parts per thousand. The CPU usage
>> of capped tasks is determined by using Kalman filters to calculate the
>> (recent) average lengths of the task's scheduling cycle and the time
>> spent on the CPU each cycle and taking the ratio of the latter to the
>> former. To minimize overhead associated with uncapped tasks these
>> statistics are not kept for them.
>>
>> Notes:
>>
>> 1. To minimize the overhead incurred when testing to skip caps processing
>> for uncapped tasks a new flag PF_HAS_CAP has been added to flags.
>
> [ot]I'm sorry to see an Australian adopt American spelling [/ot]

I think you'll find the Oxford English Dictionary (which was the
reference when I went to school in the middle of last century) uses the
z and offers the s version as an option.

>
>> 3. Enforcement of caps is not as strict as it could be in order to
>> reduce the possibility of a task being starved of CPU while holding
>> an important system resource with resultant overall performance
>> degradation. In effect, all runnable capped tasks will get some amount
>> of CPU access every active/expired swap cycle. This will be most
>> apparent for small or zero soft caps.
>
> The array swap happens very frequently if there are nothing but heavily cpu
> bound tasks, which is not an infrequent workload. I doubt the zero caps are
> very effective in that environment.

Yes and it depends on HZ as well (i.e. it works better when HZis zero).
With HZ=250 and a zero capped hard spinning task competing with
another hard spinning task on a single CPU system it struggles to keep
it below below 4%. I've tested hard caps down to 0.5% in the same test
and it copes. So a long term solution such as something similar to the
rt_mutex priority inheritance is needed so that stricter soft capping
can be enforced. I don't think that it would be hard to be more strict
as it would just involve some checking when determining idx in schedule().

BTW in my SPA schedulers this can be controlled by varying the promotion
rate.

Peter
--
Peter Williams pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-05-26 15:58    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean