bug-hurd
[Top][All Lists]
Advanced

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

EQP


From: Neal H. Walfield
Subject: EQP
Date: Thu, 30 Oct 2008 13:11:58 +0100
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Gojō) APEL/10.7 Emacs/22.2 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

Hi Jason,

It seems like you've put a lot of thought into this and come up with
some good ideas.  Thanks for sharing them with us!

At Wed, 29 Oct 2008 21:01:33 +0000,
Jason Cozens wrote:
> A basic assumption of most OS design that processors have to be kept
> busy is questioned

Can you clarify what you mean by this?  Assuming there are no adaptive
applications, a good rule of thumb is, if there is work to do and
there are available resources, use them.  When there are adaptive
applications, an adaptation should be executed if its benefit exceeds
its cost.  (The primary benefits of not using resources are saving
power and, resource use costs, e.g., for portable devices, network
costs.)  In your opinion, when should processors not be kept busy?

> and instead it is assumed that there is an abundance
> of very simple processors (1000+) and communication is cheap.

Commodity systems with 1000+ processors are, I suspect, more than 10
years off.  Current thinking is that many-core systems will be
heterogeneous, not homogeneous.  Further, they will look like
distributed systems for which communication among nodes is not that
cheap.  Moreover, they will use NUMA architectures--if they have
shared memory at all.

Would you please sketch in a bit more detail what class of systems
your algorithm is targeting.

> The versatility of a general purpose operating system often comes at the
> cost of reliability and predictability largely stemming from the
> non-deterministic programming model that is a result of its design. The
> non-determinism arises from the multiprogramming model. The ordering of
> process execution is controlled by the operating system.

I'm missing a section describing how your approach enables a
deterministic programming model.  Also, I'm missing a section on how a
program is expected to interact with the scheduler.  I feel that I
need this information before I can provide useful comments on your
approach.

> The major problem is how to manage the pool of processors. This can be
> implemented by doing away with the centralised scheduler and letting
> each processor manage itself. The problem is now really one of resource
> allocation rather than scheduling.

What's the difference between scheduling and allocation?


Neal




reply via email to

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