From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752306AbXDWUph (ORCPT ); Mon, 23 Apr 2007 16:45:37 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751965AbXDWUph (ORCPT ); Mon, 23 Apr 2007 16:45:37 -0400 Received: from mx2.mail.elte.hu ([157.181.151.9]:42243 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752306AbXDWUpg (ORCPT ); Mon, 23 Apr 2007 16:45:36 -0400 Date: Mon, 23 Apr 2007 22:44:31 +0200 From: Ingo Molnar To: Linus Torvalds Cc: Nick Piggin , Juliusz Chroboczek , Con Kolivas , ck list , Bill Davidsen , Willy Tarreau , William Lee Irwin III , linux-kernel@vger.kernel.org, Andrew Morton , Mike Galbraith , Arjan van de Ven , Peter Williams , Thomas Gleixner , caglar@pardus.org.tr, Gene Heskett Subject: Re: [REPORT] cfs-v4 vs sd-0.44 Message-ID: <20070423204431.GA1240@elte.hu> References: <200704220155.20856.kernel@kolivas.org> <20070421160008.GA28783@elte.hu> <200704220959.34978.kernel@kolivas.org> <87647oblx5.fsf@pps.jussieu.fr> <20070423013429.GB25162@wotan.suse.de> <20070423191143.GA16849@elte.hu> <20070423203317.GA26668@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070423203317.GA26668@elte.hu> User-Agent: Mutt/1.4.2.2i X-ELTE-VirusStatus: clean X-ELTE-SpamScore: -2.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-2.0 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.1.7 -2.0 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org * Ingo Molnar wrote: > (we obviously dont want to allow people to 'share' their loans with > others ;), nor do we want to allow a net negative balance. CFS is > really brutally cold-hearted, it has a strict 'no loans' policy - the > easiest economic way to manage 'inflation', besides the basic act of > not printing new money, ever.) sorry, i was a bit imprecise here. There is a case where CFS can give out a 'loan' to tasks. The scheduler tick has a low resolution, so it is fundamentally inevitable [*] that tasks will run a bit more than they should, and at a heavy context-switching rates these errors can add up significantly. Furthermore, we want to batch up workloads. So CFS has a "no loans larger than sched_granularity_ns" policy (which defaults to 5msec), and it captures these sub-granularity 'loans' with nanosec accounting. This too is a very sane economic policy and is anti-infationary :-) Ingo [*] i fundamentally hate 'fundamentally inevitable' conditions so i have plans to make the scheduler tick be fed from the rbtree and thus become a true high-resolution timer. This not only increases fairness (=='precision of scheduling') more, but it also decreases the number of timer interrupts on a running system - extending dynticks to sched-ticks too. Thomas and me shaped dynticks to enable that in an easy way: the scheduler tick is today already a high-res timer (but which is currently still driven via the jiffy mechanism).