Adrian Bunk, again (Fw: Undeliverable mail)

[David Miller <davem@davemloft.net>]

[-- Attachment #1: Type: Text/Plain, Size: 358 bytes --]


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!

[-- Attachment #2: Type: Message/Rfc822, Size: 8353 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 216 bytes --]

Your message was not delivered to the following recipients:

                  bunk@stusta.de: 554 5.7.1 <linux-kernel-owner+bunk=40stusta.de-S1763862AbXEYRPm@vger.kernel.org>: Sender address rejected: Access denied

[-- Attachment #2.1.2: Type: message/delivery-status, Size: 339 bytes --]

[-- Attachment #2.1.3: Type: message/rfc822, Size: 5975 bytes --]

From: "Li, Tong N" <tong.n.li@intel.com>
To: vatsa@in.ibm.com
Cc: William Lee Irwin III <wli@holomorphy.com>, Ingo Molnar <mingo@elte.hu>, Nick Piggin <nickpiggin@yahoo.com.au>, 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 <balbir@in.ibm.com>, linux-kernel@vger.kernel.org
Subject: Re: [RFC] [PATCH 0/3] Add group fairness to CFS
Date: Fri, 25 May 2007 10:14:58 -0700
Message-ID: <1180113298.28264.24.camel@tongli.jf.intel.com>

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/