Dataspace Allocation Size and Quota

Christian Helmuth christian.helmuth at ...1...
Tue Dec 22 15:41:20 CET 2015


Hi Georg,

in addition to Norman's remarks I further investigated your issue
(mostly because the value 32769 which is 0x8001 puzzled me).

On 22.12.2015 14:00, Georg Guba wrote:
> This shows 0/32769 on the first print and 28672/32769 on the second
> which is exactly what you'd expect. Allocating 29 KiB with a 32 KiB
> quota, however, will throw a Quota_exceeded exception, still printing
> 0/32769 on the first print.
> 
> It seems you need about 4 KiB of spare quota but I can't seem to find
> any doc on this. How much quota should I actually reserve for simple
> allocations like this and why isn't it simply the same as the actual
> allocation size? I'd like to avoid magic numbers and wasteful allocation
> if possible.

With the patch applied I get the following output on linux_x86.

  [init -> test-printf] 0/0
  [init -> test-printf] 0/32768
  [init -> test-printf] 16384/32768

So it's 0x8000 indeed and I assume a typo on your side. But, the
actual question is: Why can't one use the final 4 KiB of the RAM
quota? The answer leads us to the implementation of
Ram_session_component in core, which dates back several years and
includes the following comment in Ram_session_component::alloc().

  /*
   * Check quota!
   *
   * In the worst case, we need to allocate a new slab block for the
   * meta data of the dataspace to be created - therefore, we add
   * the slab block size here.
   */

Unfortunately, this piece of code does not (and currently can't) use
the available bytes in the meta-data allocator but in the RAM session
itself. It is remnant of the ongoing process of decoupling RAM
allocations from meta-data handling.

Thanks for sharing your findings, we'll address the issue with

  https://github.com/genodelabs/genode/issues/1831

For now, the last 4 KiB of the RAM session quota are beyond reach,
sorry.

Regards
-- 
Christian Helmuth
Genode Labs

http://www.genode-labs.com/ · http://genode.org/
https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
-------------- next part --------------
A non-text attachment was scrubbed...
Name: printf.patch
Type: text/x-diff
Size: 1348 bytes
Desc: not available
URL: <http://lists.genode.org/pipermail/users/attachments/20151222/8966cd05/attachment.patch>


More information about the users mailing list