Re: Scheduling Memory in Viengoos

[Bas Wijnen]

Hi,

First of all, thanks Neal for this info.  It's nice to hear something
about the state of things.

On Thu, Jun 26, 2008 at 12:59:08PM +0200, Neal H. Walfield wrote:
> Principals (called activities)

So they are synonymous?  Why do you have two words for this concept?

> As long as there is memory available, memory allocations are granted.

I understand from your explanation that any activity can reserve some
memory, and it can claim as much memory as it likes, as long as it is
available.  Then when memory is exhausted, some activity's memory will
be shrunk, but never further than the reserved amount.  Is that correct?

Does an activity for which the allocation is shrunk get a notification
and can it somehow save the contents?  Or should every page which is not
reserved be considered cache which can disappear without notice?

> When this is no longer the case, Viengoos must decide which activity
> must yield memory.  This is accomplished by walking the activity
> hierarchy starting at the root to find the activity that most exceeds
> its share according to its scheduling parameters.

Can activities create children without limits?  In that case, this
tree-walking does not have an upper limit on its completion time?

> (As nodes as well as leaves
> can allocate memory, each activity actually has two scheduling
> policies: a child relative policy and a sibling relative policy.  The
> sibling relative policy may only be set by the activity controller.

Which is usually the parent node?

Is child memory available to the parents (direct and indirect)?

> When we report the availability to the child, we will not report 35,
> but perhaps 34 so as to encourage it to free a bit more memory.

A well behaving child would gladly do this, while a badly behaving child
wouldn't do it anyway, right?  Why then not just give real numbers (35)
and let the child be nice explicitly?

> Availability, along with some other statistics, is regenerated for
> each active activity about every 2 seconds.  A thread can wait for
> these statistics and when they are made available, it is notified.
>
> This removes the need for polling.

That is always good. :-)

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html

signature.asc
Description: Digital signature