Message-Id: <20070525.132317.38714868.davem@davemloft.net>
Date:	Fri, 25 May 2007 13:23:17 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	linux-kernel@...r.kernel.org
Subject: Adrian Bunk, again (Fw: Undeliverable mail)


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!

Return-Path: <davem@...r.kernel.org>
X-Original-To: davem@...set.davemloft.net
Delivered-To: davem@...set.davemloft.net
Received: from vger.kernel.org (vger.kernel.org [209.132.176.167])
	by sunset.davemloft.net (Postfix) with ESMTP id 5AC3A29002D
	for <davem@...set.davemloft.net>; Fri, 25 May 2007 10:17:31 -0700 (PDT)
Received: (from localhost user: 'davem' uid#2109 fake: STDIN
	(davem@...r.kernel.org)) by vger.kernel.org id S1761386AbXEYRR0
	(ORCPT <rfc822;davem@...set.davemloft.net>);
	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
	<rfc822;linux-kernel-owner+bunk=40stusta.de-S1763862AbXEYRPm@...r.kernel.org>);
	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@...r.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: <iss.9c0ac906.7696.46571a24.88abf.1@...lrelay1.lrz-muenchen.de>
Date:	Fri, 25 May 2007 19:17:24 +0200
Sender:	"David S. Miller" <davem@...r.kernel.org>
From:	mailer-daemon@...-muenchen.de
To:	linux-kernel-owner+bunk=40stusta.de-S1763862AbXEYRPm@...r.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@...sta.de: 554 5.7.1 <linux-kernel-owner+bunk=40stusta.de-S1763862AbXEYRPm@...r.kernel.org>: 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@...sta.de
Final-Recipient: rfc822;bunk@...sta.de
Action: failed
Status: 5.5.0
Remote-MTA: dns;emailhub.stusta.mhn.de
Diagnostic-Code: smtp;554 5.7.1 <linux-kernel-owner+bunk=40stusta.de-S1763862AbXEYRPm@...r.kernel.org>: Sender address rejected: Access denied

--=_mh.ndn.7696.46571a24_=
Content-Type: message/rfc822

Return-Path: <linux-kernel-owner+bunk=40stusta.de-S1763862AbXEYRPm@...r.kernel.org>
Received: from lxmhs06.lrz-muenchen.de (lxmhs06.lrz-muenchen.de [10.156.6.203]) by mailrelay1.lrz-muenchen.de with ESMTP for bunk@...sta.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 <bunk@...sta.de>;
	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@...sta.de; Fri, 25 May 2007 19:17:22 +0200
Received: (majordomo@...r.kernel.org) by vger.kernel.org via listexpand
	id S1763862AbXEYRPm (ORCPT <rfc822;bunk@...sta.de>);
	Fri, 25 May 2007 13:15:42 -0400
Received: (majordomo@...r.kernel.org) by vger.kernel.org id S1750861AbXEYRPg
	(ORCPT <rfc822;linux-kernel-outgoing>);
	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 <rfc822;linux-kernel@...r.kernel.org>);
	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" <tong.n.li@...el.com>
To: vatsa@...ibm.com
Cc: William Lee Irwin III <wli@...omorphy.com>,
    Ingo Molnar <mingo@...e.hu>,
    Nick Piggin <nickpiggin@...oo.com.au>,
    efault@....de,
    kernel@...ivas.org,
    containers@...ts.osdl.org,
    ckrm-tech@...ts.sourceforge.net,
    torvalds@...ux-foundation.org,
    akpm@...ux-foundation.org,
    pwil3058@...pond.net.au,
    tingy@...umass.edu,
    Balbir Singh <balbir@...ibm.com>,
    linux-kernel@...r.kernel.org
In-Reply-To: <20070525161424.GA5162@...ibm.com>
References: <20070523164859.GA6595@...ibm.com>
	 <20070523180316.GY19966@...omorphy.com>  <20070525161424.GA5162@...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@...gli.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@...r.kernel.org
Precedence: bulk
X-Mailing-List:	linux-kernel@...r.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@...r.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_=--

Powered by blists - more mailing lists