Adrian Bunk, again (Fw: Undeliverable mail)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

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!
--- Begin Message --- 
Your message was not delivered to the following recipients:

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

Reporting-MTA: dns;mailrelay1.lrz-muenchen.de

Original-Recipient: rfc822;[email protected]
Final-Recipient: rfc822;[email protected]
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@vger.kernel.org>: Sender address rejected: Access denied
--- Begin Message --- 
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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

--- End Message ---

--- End Message ---
[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux