From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750809AbWFPAua (ORCPT ); Thu, 15 Jun 2006 20:50:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750810AbWFPAua (ORCPT ); Thu, 15 Jun 2006 20:50:30 -0400 Received: from e1.ny.us.ibm.com ([32.97.182.141]:63104 "EHLO e1.ny.us.ibm.com") by vger.kernel.org with ESMTP id S1750809AbWFPAua (ORCPT ); Thu, 15 Jun 2006 20:50:30 -0400 Subject: Re: [RFC] CPU controllers? From: Matt Helsley To: Peter Williams Cc: vatsa@in.ibm.com, Sam Vilain , Kirill Korotaev , Mike Galbraith , Ingo Molnar , Nick Piggin , Andrew Morton , "Chandra S. Seetharaman" , Balbir Singh , LKML In-Reply-To: <4491ED7B.2000003@bigpond.net.au> References: <20060615134632.GA22033@in.ibm.com> <4491ED7B.2000003@bigpond.net.au> Content-Type: text/plain Date: Thu, 15 Jun 2006 17:42:49 -0700 Message-Id: <1150418569.21787.456.camel@stark> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2006-06-16 at 09:30 +1000, Peter Williams wrote: > Srivatsa Vaddagiri wrote: > > * Supports hard limit and soft limit > > * Introduces new task priorities where tasks that have exceeded their > > soft limit can be "parked" until the O(1) scheduler picks them for > > execution > > * Load balancing on SMP systems made aware of tasks whose execution > > rate is limited by this feature > > * Patch is simple > > > > Limitations: > > * Does not support guarantee > > Why would a capping mechanism support guarantees? The two mechanisms > can be implemented separately. The only interaction between them that > is required is a statement about which has precedence. I.e. if a cap is > less than a guarantee is it enforced? I would opine that it should be. When this combination occurs userspace is crazy/uncoordinated/dumb and can't be "satisfied". Perhaps the better approach is to ignore both guarantee and limit (cap) in this case -- treat it as if userspace hasn't specified either. Alternatively the kernel can refuse to allow configuring such a combination in the first place. This is one reason tying guarantees and limits (caps) into the same framework would be useful. Cheers, -Matt Helsley