From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754015AbXDRTo1 (ORCPT ); Wed, 18 Apr 2007 15:44:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754043AbXDRTo1 (ORCPT ); Wed, 18 Apr 2007 15:44:27 -0400 Received: from mx3.mail.elte.hu ([157.181.1.138]:47435 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754015AbXDRTo0 (ORCPT ); Wed, 18 Apr 2007 15:44:26 -0400 Date: Wed, 18 Apr 2007 21:43:39 +0200 From: Ingo Molnar To: Linus Torvalds Cc: Matt Mackall , Nick Piggin , William Lee Irwin III , Peter Williams , Mike Galbraith , Con Kolivas , ck list , Bill Huey , linux-kernel@vger.kernel.org, Andrew Morton , Arjan van de Ven , Thomas Gleixner Subject: Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS] Message-ID: <20070418194339.GA26739@elte.hu> References: <20070418031511.GA18452@wotan.suse.de> <20070418043831.GR11115@waste.org> <20070418050024.GF18452@wotan.suse.de> <20070418055525.GS11115@waste.org> <20070418152355.GU11115@waste.org> <20070418174945.GA7930@elte.hu> <20070418175936.GA11980@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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.0.3 -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 * Linus Torvalds wrote: > For example, maybe we can approximate it by spreading out the > statistics: right now you have things like > > - last_ran, wait_runtime, sum_wait_runtime.. > > be per-thread things. [...] yes, yes, yes! :) My thinking is "struct sched_group" embedded into _arbitrary_ other resource containers and abstractions, which sched_group's are then in a simple hierarchy and are driven by the core scheduling machinery. > [...] Maybe some of those can be spread out, so that you put a part of > them in the "struct vm_struct" thing (to approximate processes), part > of them in the "struct user" struct (to approximate the user-level > thing), and part of it in a per-container thing for when/if we support > that kind of thing? yes. Ingo