Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161236AbWHDOrz (ORCPT ); Fri, 4 Aug 2006 10:47:55 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1161246AbWHDOrz (ORCPT ); Fri, 4 Aug 2006 10:47:55 -0400 Received: from e32.co.us.ibm.com ([32.97.110.150]:53453 "EHLO e32.co.us.ibm.com") by vger.kernel.org with ESMTP id S1161244AbWHDOry (ORCPT ); Fri, 4 Aug 2006 10:47:54 -0400 Date: Fri, 4 Aug 2006 20:21:58 +0530 From: Srivatsa Vaddagiri To: Kirill Korotaev Cc: Ingo Molnar , Nick Piggin , Sam Vilain , linux-kernel@vger.kernel.org, Kirill Korotaev , Mike Galbraith , Balbir Singh , sekharan@us.ibm.com, Andrew Morton , nagar@watson.ibm.com, haveblue@us.ibm.com, pj@sgi.com Subject: Re: [ RFC, PATCH 1/5 ] CPU controller - base changes Message-ID: <20060804145158.GA29850@in.ibm.com> Reply-To: vatsa@in.ibm.com References: <20060804050753.GD27194@in.ibm.com> <20060804050932.GE27194@in.ibm.com> <44D35AD8.2090506@sw.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44D35AD8.2090506@sw.ru> User-Agent: Mutt/1.5.11 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1535 Lines: 41 On Fri, Aug 04, 2006 at 06:34:00PM +0400, Kirill Korotaev wrote: > Srivatsa, > > AFAICS, you wanted to go the way we used in OpenVZ - 2-level scheduling. > However, you don't do any process balancing between runqueues taking into > account > other groups. > In many cases you will simply endup with tasks collected on the same > physical > CPU and poor performance. I'm not talking about fairness (proportinal CPU > scheduling). > I don't think it is possible to make any estimations for QoS of such a > scheduler. Yes, the patch (as mentioned earlier) does not address SMP correctness _yet_. That will need to be addressed definitely for an acceptable controller. My thought was we could try the smpnice approach (which attempts to deal with the same problem albeit for niced tasks) and see how far we can go. I am planning to work on it next. > What do you think about a full runqueue virtualization, so that > first level CPU scheduler could select task-group on any basis and then > arbitrary runqueue was selected for running? That may solve the load balance problem nicely. But isnt there some cost to be paid for it (like lock contention on the virtual runqueues)? > P.S. BTW, this patch doesn't allow hierarchy in CPU controler. Do we want heriarchy? -- Regards, vatsa - 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/