l4-hurd
[Top][All Lists]
Advanced

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

Re: Resource Allocation Strategy


From: olafBuddenhagen
Subject: Re: Resource Allocation Strategy
Date: Thu, 2 Aug 2007 21:05:27 +0200
User-agent: Mutt/1.5.16 (2007-06-11)

Hi,

On Fri, Jul 13, 2007 at 02:31:37PM +0200, Neal H. Walfield wrote:

> When an activity acts as a resource scheduler for its children, it has
> maximum control over how resources are allocated between them.  In
> principle, this allows the realization of most any conceivable
> allocation policy or mechanism a developer may desire.  This control
> has a number of costs.  There are computation costs in terms of
> interposition and bookkeeping.  There is also the cost of added
> complexity.  And, there are questions.  If components are often
> combined, how much freedom do developers really have?  Equally
> important, to what degree do developers require such control?

I totally agree that a decentralized approach causes a lot of overhead;
and in a traditional system, where everything interacts quite
intimately, it's probably not worth it because of other constraints.

Yet, I'm not sure the option of decentralized management should be
completely discarded. Think of virtual machines: In this case, it's
totally out of question to have a central resource manager that controls
all allocations within the guest systems. The guests want to keep total
control over how things are managed inside their VMs.

Traditionally, the resources for VMs are allocated statically, which is
a total waste of course. So it is desirable to have a mechanism where
the guests have full control over their VMs, yet can interact with the
host to dynamically manage resources for the whole VM. (A while back I
learned that Xen is working on something like that; no idea what became
of it...)

The current popularity of VMs shows that in many cases, the benefits of
the strong isolation outweigh the disadvantages of missing
centralization and integration. Of course, the ability to relatively
easily create custom sub-environments in the Hurd is not quite
comparable to full-blown VMs; yet it might be an interesting direction
to look in...

-antrik-




reply via email to

[Prev in Thread] Current Thread [Next in Thread]