Messages in this thread | | | Date | Sat, 27 May 2006 00:00:50 +1000 | From | Peter Williams <> | Subject | Re: [RFC 0/5] sched: Add CPU rate caps |
| |
Con Kolivas wrote: > On Friday 26 May 2006 14:20, Peter Williams wrote: >> These patches implement CPU usage rate limits for tasks. >> >> Although the rlimit mechanism already has a CPU usage limit (RLIMIT_CPU) >> it is a total usage limit and therefore (to my mind) not very useful. >> These patches provide an alternative whereby the (recent) average CPU >> usage rate of a task can be limited to a (per task) specified proportion >> of a single CPU's capacity. The limits are specified in parts per >> thousand and come in two varieties -- hard and soft. The difference >> between the two is that the system tries to enforce hard caps regardless >> of the other demand for CPU resources but allows soft caps to be >> exceeded if there are spare CPU resources available. By default, tasks >> will have both caps set to 1000 (i.e. no limit) but newly forked tasks >> will inherit any caps that have been imposed on their parent from the >> parent. The mimimim soft cap allowed is 0 (which effectively puts the >> task in the background) and the minimim hard cap allowed is 1. >> >> Care has been taken to minimize the overhead inflicted on tasks that >> have no caps and my tests using kernbench indicate that it is hidden in >> the noise. > > The presence of tasks with caps will break smp balancing and smp nice. I > suspect you could probably provide a reasonable workaround by altering their > priority bias effect in the raw weighted load in smp nice for soft caps by > the percentage cpu of the cap. Hard caps provide more "interesting" > challenges though. I can't think of a valid biasing off hand for them, but at > least initially using the same logic as soft caps should help. >
I thought that I already did that? Check the changes to set_load_weight().
-- 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/
| |