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 [email protected]
"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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
