From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761510AbXEYUXX (ORCPT ); Fri, 25 May 2007 16:23:23 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753033AbXEYUXP (ORCPT ); Fri, 25 May 2007 16:23:15 -0400 Received: from 74-93-104-97-Washington.hfc.comcastbusiness.net ([74.93.104.97]:41808 "EHLO sunset.davemloft.net" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1751360AbXEYUXO (ORCPT ); Fri, 25 May 2007 16:23:14 -0400 Date: Fri, 25 May 2007 13:23:17 -0700 (PDT) Message-Id: <20070525.132317.38714868.davem@davemloft.net> To: linux-kernel@vger.kernel.org Subject: Adrian Bunk, again (Fw: Undeliverable mail) From: David Miller X-Mailer: Mew version 5.1.52 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_May_25_13_23_17_2007_787)--" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org ----Next_Part(Fri_May_25_13_23_17_2007_787)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Can someone tell Adrian that he's bouncing with 500 level errors, like the one attached below, again? Could you also tell him to start using a different email account for his vger.kernel.org subscriptions as this is starting to get rediculious. I think I've been beyond reasonable trying to help him out with this problem and it's not improving. Thanks! ----Next_Part(Fri_May_25_13_23_17_2007_787)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Original-To: davem@sunset.davemloft.net Delivered-To: davem@sunset.davemloft.net Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by sunset.davemloft.net (Postfix) with ESMTP id 5AC3A29002D for ; Fri, 25 May 2007 10:17:31 -0700 (PDT) Received: (from localhost user: 'davem' uid#2109 fake: STDIN (davem@vger.kernel.org)) by vger.kernel.org id S1761386AbXEYRR0 (ORCPT ); Fri, 25 May 2007 13:17:26 -0400 Received: from mailrelay3.lrz-muenchen.de ([129.187.254.101]:49548 "EHLO mailrelay3.lrz-muenchen.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752758AbXEYRR0 (ORCPT ); Fri, 25 May 2007 13:17:26 -0400 Received: from mailrelay1.lrz-muenchen.de (mailrelay1.lrz-muenchen.de [129.187.254.106]) by mailrelay3.lrz-muenchen.de with ESMTP for linux-kernel-owner+bunk=40stusta.de-S1763862AbXEYRPm@vger.kernel.org; Fri, 25 May 2007 19:17:24 +0200 Received: by mailrelay1.lrz-muenchen.de; Fri, 25 May 2007 19:17:24 +0200 Message-Id: Date: Fri, 25 May 2007 19:17:24 +0200 Sender: "David S. Miller" From: mailer-daemon@lrz-muenchen.de To: linux-kernel-owner+bunk=40stusta.de-S1763862AbXEYRPm@vger.kernel.org Subject: Undeliverable mail MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="=_mh.ndn.7696.46571a24_=" --=_mh.ndn.7696.46571a24_= Content-Type: text/plain; charset=us-ascii Your message was not delivered to the following recipients: bunk@stusta.de: 554 5.7.1 : Sender address rejected: Access denied --=_mh.ndn.7696.46571a24_= Content-Type: message/delivery-status Content-Transfer-Encoding: 7bit Reporting-MTA: dns;mailrelay1.lrz-muenchen.de Original-Recipient: rfc822;bunk@stusta.de Final-Recipient: rfc822;bunk@stusta.de Action: failed Status: 5.5.0 Remote-MTA: dns;emailhub.stusta.mhn.de Diagnostic-Code: smtp;554 5.7.1 : Sender address rejected: Access denied --=_mh.ndn.7696.46571a24_= Content-Type: message/rfc822 Return-Path: Received: from lxmhs06.lrz-muenchen.de (lxmhs06.lrz-muenchen.de [10.156.6.203]) by mailrelay1.lrz-muenchen.de with ESMTP for bunk@stusta.de; Fri, 25 May 2007 19:17:23 +0200 X-Virus-Scanned: by amavisd-new at lrz-muenchen.de in 06 X-Spam-Score: 1.691 X-Spam-Level: * X-Spam-Status: No, score=1.691 tagged_above=-999 required=5 tests=[AWL=-0.377, BAYES_50=0.001, RCVD_NUMERIC_HELO=2.067] Received: from mailrelay1.lrz-muenchen.de ([10.156.6.201]) by lxmhs06.lrz-muenchen.de (lxmhs06.lrz-muenchen.de [10.156.6.203]) (amavisd-new, port 10024) with ESMTP id oOXmsM1LzT-M for ; Fri, 25 May 2007 19:17:23 +0200 (CEST) Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by mailrelay1.lrz-muenchen.de with ESMTP for bunk@stusta.de; Fri, 25 May 2007 19:17:22 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763862AbXEYRPm (ORCPT ); Fri, 25 May 2007 13:15:42 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750861AbXEYRPg (ORCPT ); Fri, 25 May 2007 13:15:36 -0400 Received: from mga09.intel.com ([134.134.136.24]:60881 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752689AbXEYRPf (ORCPT ); Fri, 25 May 2007 13:15:35 -0400 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP; 25 May 2007 10:15:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.14,580,1170662400"; d="scan'208";a="90533813" Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by fmsmga002.fm.intel.com with ESMTP; 25 May 2007 10:15:04 -0700 Received: from fmsmsx411.amr.corp.intel.com ([10.19.28.152]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 10:14:59 -0700 Received: from 134.134.213.19 ([134.134.213.19]) by fmsmsx411.amr.corp.intel.com ([10.19.28.152]) via Exchange Front-End Server email.intel.com ([192.168.65.24]) with Microsoft Exchange Server HTTP-DAV ; Fri, 25 May 2007 17:14:58 +0000 Received: from tongli.jf.intel.com by email.intel.com; 25 May 2007 10:14:58 -0700 Subject: Re: [RFC] [PATCH 0/3] Add group fairness to CFS From: "Li, Tong N" To: vatsa@in.ibm.com Cc: William Lee Irwin III , Ingo Molnar , Nick Piggin , efault@gmx.de, kernel@kolivas.org, containers@lists.osdl.org, ckrm-tech@lists.sourceforge.net, torvalds@linux-foundation.org, akpm@linux-foundation.org, pwil3058@bigpond.net.au, tingy@cs.umass.edu, Balbir Singh , linux-kernel@vger.kernel.org In-Reply-To: <20070525161424.GA5162@in.ibm.com> References: <20070523164859.GA6595@in.ibm.com> <20070523180316.GY19966@holomorphy.com> <20070525161424.GA5162@in.ibm.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 25 May 2007 10:14:58 -0700 Message-Id: <1180113298.28264.24.camel@tongli.jf.intel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-OriginalArrivalTime: 25 May 2007 17:14:59.0106 (UTC) FILETIME=[391F9820:01C79EF0] Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2007-05-25 at 21:44 +0530, Srivatsa Vaddagiri wrote: > > > > That assumes per-user scheduling groups; other configurations would > > make it one step for each level of hierarchy. It may be possible to > > reduce those steps to only state transitions that change weightings > > and incremental updates of task weightings. By and large, one needs > > the groups to determine task weightings as opposed to hierarchically > > scheduling, so there are alternative ways of going about this, ones > > that would even make load balancing easier. > > Yeah I agree that providing hierarchical group-fairness at the cost of single > (or fewer) scheduling levels would be a nice thing to target for, > although I don't know of any good way to do it. Do you have any ideas > here? Doing group fairness in a single level, using a common rb-tree for tasks > from all groups is very difficult IMHO. We need atleast two levels. > > One possibility is that we recognize deeper hierarchies only in user-space, > but flatten this view from kernel perspective i.e some user space tool > will have to distributed the weights accordingly in this flattened view > to the kernel. Nice work, Vatsa. When I wrote the DWRR algorithm, I flattened the hierarchies into one level, so maybe that approach can be applied to your code as well. What I did is to maintain task and task group weights and reservations separately from the scheduler, while the scheduler only sees one system-wide weight per task and does not concern about which group a task is in. The key here is the system-wide weight of each task should represent an equivalent share to the share represented by the group hierarchies. To do this, the scheduler looks up the task and group weights/reservations it maintains, and dynamically computes the system-wide weight *only* when it need a weight for a given task while scheduling. The on-demand weight computation makes sure the cost is small (constant time). The computation itself can be seen from an example: assume we have a group of two tasks and the group's total share is represented by a weight of 10. Inside the group, let's say the two tasks, P1 and P2, have weights 1 and 2. Then the system-wide weight for P1 is 10/3 and the weight for P2 is 20/3. In essence, this flattens weights into one level without changing the shares they represent. tong - 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/ --=_mh.ndn.7696.46571a24_=-- ----Next_Part(Fri_May_25_13_23_17_2007_787)----