Re: [ckrm-tech] phys memory controller

[Gerrit H. <gh...@us...>]

On Wed, 21 Jul 2004 12:03:59 PDT, Chandra Seetharaman wrote:
> On Wed, Jul 21, 2004 at 02:32:08PM -0400, Marc E. Fiuczynski wrote:
> > Marc wrote:
> > >> Could you explain again how your physical memory
> > >> controller will work? From what I remember, there
> > >> will be a specified quota that is only enforced when
> > >> the system runs into memory pressure. Is that right?
> > >> Is there a way to also specify a hard upperbound?
> > 
> > Chandra replied:
> > >That will be used for guarantee. I am planning to use
> > >'limit' during allocation of a page.
> > 
> > Not sure how to parse what you are saying. Does 'guarantee' and 'limit'
> > somehow translate into 'soft' and 'hard' upper bounds? If so, might I
> > suggest that you call them 'softupperbound' and 'hardupperbound' in your
> > config files, so that they are in a sense self documenting and immediately
> > obvious to someone looking at the appropriate /rcfs/ files.
> 
> It is same as the description of guarantee and limit as described in the
> CKRM document(http://ckrm.sourceforge.net/CKRMmergedAPI-d6.txt)
> 
> "my_guarantee" is the amount of resource that is guaranteed to a class
> and "my_limit" is the maximum amount of resource a class can get.
> 
> At any point in time a class can use resource with 0 to "my_guarantee",
> and may get resource if its current usage is greater than "my_guarantee"
> upto "my_limit" depending on the current usage of the resource in the
> system(more specifically under its parent).
> 
> Your description of softupperbound and hardupperbound would mean the same.
> We went with this interface as it was easy to describe when hierarchy is
> involved. Since, the interface is consistent across resource controllers, I
> don't think I can change it.
> 
> comments anybody (on softupperbound/hardupperbound Vs my_guarantee/my_limit) ?

Chandra, Linus disliked the word guarantee; it hinted at potential
deadlocks due to, effectively, priority inversion.  E.g., a task which
was allocated 2% of the CPU might prevent a task which was allocated
98% of the CPU from making progress.  Also, guarantee is a very strong
word and would be impossible in the case of, say, oversubscription of
a resource.

I think the soft/hard limit is a better wording (e.g. getrlimit() style).

gerrit