From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161373AbXDQWVr (ORCPT ); Tue, 17 Apr 2007 18:21:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1161380AbXDQWVr (ORCPT ); Tue, 17 Apr 2007 18:21:47 -0400 Received: from waste.org ([66.93.16.53]:54098 "EHLO waste.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161373AbXDQWVq (ORCPT ); Tue, 17 Apr 2007 18:21:46 -0400 Date: Tue, 17 Apr 2007 17:08:09 -0500 From: Matt Mackall To: Ingo Molnar Cc: William Lee Irwin III , Davide Libenzi , Nick Piggin , Peter Williams , Mike Galbraith , Con Kolivas , ck list , Bill Huey , Linux Kernel Mailing List , Linus Torvalds , Andrew Morton , Arjan van de Ven , Thomas Gleixner Subject: Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS] Message-ID: <20070417220809.GF11166@waste.org> References: <20070417034050.GD25513@wotan.suse.de> <46244A52.4000403@bigpond.net.au> <20070417042954.GG25513@wotan.suse.de> <20070417060955.GO8915@holomorphy.com> <20070417061503.GC1057@wotan.suse.de> <20070417070949.GR8915@holomorphy.com> <20070417073308.GB30559@elte.hu> <20070417090538.GU8915@holomorphy.com> <20070417092422.GA19414@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070417092422.GA19414@elte.hu> User-Agent: Mutt/1.5.13 (2006-08-11) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 17, 2007 at 11:24:22AM +0200, Ingo Molnar wrote: > > * William Lee Irwin III wrote: > > > [...] Also rest assured that the tone of the critique is not hostile, > > and wasn't meant to sound that way. > > ok :) (And i guess i was too touchy - sorry about coming out swinging.) > > > Also, given the general comments it appears clear that some > > statistical metric of deviation from the intended behavior furthermore > > qualified by timescale is necessary, so this appears to be headed > > toward a sort of performance metric as opposed to a pass/fail test > > anyway. However, to even measure this at all, some statement of > > intention is required. I'd prefer that there be a Linux-standard > > semantics for nice so results are more directly comparable and so that > > users also get similar nice behavior from the scheduler as it varies > > over time and possibly implementations if users should care to switch > > them out with some scheduler patch or other. > > yeah. If you could come up with a sane definition that also translates > into low overhead on the algorithm side that would be great! How's this: If you're running two identical CPU hog tasks A and B differing only by nice level (Anice, Bnice), the ratio cputime(A)/cputime(B) should be a constant f(Anice - Bnice). Other definitions make things hard to analyze and probably not well-bounded when confronted with > 2 tasks. I -think- this implies keeping a separate scaled CPU usage counter, where the scaling factor is a trivial exponential function of nice level where f(0) == 1. Then you schedule based on this scaled usage counter rather than unscaled. I also suspect we want to keep the exponential base small so that the maximal difference is 10x-100x. -- Mathematics is the supreme nostalgia of our time.