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