From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751230AbWE0BlE (ORCPT ); Fri, 26 May 2006 21:41:04 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751750AbWE0BlE (ORCPT ); Fri, 26 May 2006 21:41:04 -0400 Received: from omta05ps.mx.bigpond.com ([144.140.83.195]:37199 "EHLO omta05ps.mx.bigpond.com") by vger.kernel.org with ESMTP id S1751230AbWE0BlC (ORCPT ); Fri, 26 May 2006 21:41:02 -0400 Message-ID: <4477AE2B.60204@bigpond.net.au> Date: Sat, 27 May 2006 11:40:59 +1000 From: Peter Williams User-Agent: Thunderbird 1.5.0.2 (X11/20060501) MIME-Version: 1.0 To: balbir@in.ibm.com CC: Mike Galbraith , Con Kolivas , Linux Kernel , Kingsley Cheung , Ingo Molnar , Rene Herman Subject: Re: [RFC 0/5] sched: Add CPU rate caps References: <20060526042021.2886.4957.sendpatchset@heathwren.pw.nest> <20060526112939.GA29109@in.ibm.com> In-Reply-To: <20060526112939.GA29109@in.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at omta05ps.mx.bigpond.com from [147.10.133.38] using ID pwil3058@bigpond.net.au at Sat, 27 May 2006 01:41:00 +0000 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Balbir Singh wrote: > On Fri, May 26, 2006 at 02:20:21PM +1000, 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. >> >> Note: >> >> The first patch in this series fixes some problems with priority >> inheritance that are present in 2.6.17-rc4-mm3 but will be fixed in >> the next -mm kernel. >> > > 1000 sounds like a course number. A good estimate for the user setting > these limits would be percentage or better yet let the user decide on the > parts. For example, the user could divide the available CPU's capacity > to 2000 parts and ask for 200 parts or divide into 100 parts and as for 10 > parts. The default capacity can be 100 or 1000 parts. May be the part > setting could be a system tunable. > > I would also prefer making the capacity defined as the a specified portion > of the capacity of all CPU's. This would make the behaviour more predictable. The meaning of a cap would change every time you took a CPU off/on line. This makes the behaviour less predictable not more predictable (at least in my opinion). You also have the possibility of a cap being larger than the capacity of a single CPU which doesn't make sense when capping at the task level. However, if you still preferred that interface, it could be implemented as a wrapper around these functionalities out in user space or inside a resource management component. > > Consider a task "T" which has 10 percent of a single CPU's capacity as hard > limit. If it migrated to another CPU, would the new CPU also make 10% of its > capacity available "T". > > What is the interval over which the 10% is tracked? Does the task that crosses > its hard limit get killed? If not, When does a task which has exceeded its > hard-limit get a new lease of another 10% to use? > > I guess I should move on to reading the code for this feature now :-) I look forward to your comments. Peter -- Peter Williams pwil3058@bigpond.net.au "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce