Number of components per init

Roman Iten roman.iten at ...453...
Wed Oct 5 11:55:37 CEST 2016

Hi Norman

Thanks for the insights. I still don't understand why init's(?) quota 
exceeds. I get the warning no matter of the presence of the "overly 
large quantum". Is this behavior intended?

- How big is the initial quota of init?

- Can I change that quota - or only the preserved slack memory?

- If not - is there another way to prevent the "Quota exceeded!" 

- Does the size of the metadata allocation for a child depends on 
whether I'm using a 32 or 64 bit system?

- Is a scenario with 19 or more components within one init considered 


On Mit, Okt 5, 2016 at 9:05 , Norman Feske 
<norman.feske at ...1...> wrote:
> Hi Roman,
> On 04.10.2016 20:04, Roman Iten wrote:
>>  Hi, I wrote a simple run script 'manytimer', based on 'timer':
>> When the number of
>>  components exceeds 19, I get a "Quota exceeded!" warning. It seems 
>> that
>>  it doesn't matter if I use timer or other components. It also 
>> doesn't
>>  matter how much RAM quota I configure per timer. - Is this behaviour
>>  intended? - Whose quota exceeds (init, core, ...)? - Can I resolve 
>> the
>>  warning by increasing its quota? - In a scenario with 19 or more
>>  components (within one init), is it still possible to "assign all
>>  remaining resources to the last child by simply specifying an overly
>>  large quantum" as described in "Genode 16.05 Foundations" (see 
>> Chapter
>>  6.2.2 "Resource quota saturation"). Or would there be no more slack
>>  memory available for init and core respectively?
> I encountered the same problem in the Turmvilla scenario. In the
> presence of the "overly large quantum", init transfers all remaining
> quota from itself to the corresponding child and preserves just a tiny
> bit of quota for itself. This preserved quota is needed to accommodate
> the few metadata allocations that cannot be easily allocated from a
> specific child (i.e., child-thread meta data). If the number of 
> children
> becomes too large, this preservation does not suffice. But you can
> increase the value as done by the following commit:
> Cheers
> Norman
> --
> Dr.-Ing. Norman Feske
> Genode Labs
> ·
> Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
> Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites,!
> _______________________________________________
> genode-main mailing list
> genode-main at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list