Hi Adrian,
š
thank you for reply.
Yes, you are right, I assumed another thing. I don't understand how the pool size is related to thread's available workspace. You wrote, that pools are needed for allocating of book keeping info. In this case is book keeping info a page table (PT) or a page directory (PD)?
If the pool is needed for PD/PT what is the method to count the size of the memory the process is capable to use. If the pool is not for PT/PD how does it influence on memory size the process is allowed to use.
Could you please comment on dependency between the pool size and available memory of the second thread.
In general, I want to share memory between threads, and I believe, that knowledge about pools, can help me.
š
--š
Best Regards,
Rinat Dobrokhotov
š
š
š
30.05.2016, 02:08, "Adrian Danis" <adrian.danis@nicta.com.au>:
HI Rinat,

I'm not entirely certain what you are asking, but I can explain what the static and virtual pools are, which might indirectly answer your question.

The static and virtual pools can be thought of as just being another heap. Allocman uses these to allocate book keeping data in preference to the regular C heap due to usage in environments where the C heap is either not implemented or is implemented using allocman.

Two pools are needed, one static and one virtual, because the virtual pool (along with the rest of allocman) require memory in order to bootstrap. Once bootstrapping is done then provided the system does not run out of memory enough space in the virtual pool will also be reserved to ensure that if the virtual pool needs to grow, there is enough memory for any book keeping required.

All of this complexity comes about due to the circular dependencies on allocating resources. These dependencies are loosely described as
* Capability slots: Allocated from untypeds, book kept in memory
* Untypeds / other objects (including frame objects): Allocated from other untypeds, into capability slots, book kept in memory
* memory: Requires frame object

Initially, because of these circular dependencies, nothing can be allocated. The static pool provides a way to inject one of the dependencies and try and start the cycle.

Note that these dependencies and complications only exist if you want to be able to track, book keep, free and reuse all allocations. If you want a simpler 'allocate only' system, that does not require book keeping to support free, then these problems don't exist.

Adrian

On Sun 29-May-2016 1:49 AM, äÏÂÒÏÈÏÔÏ× òÉÎÁÔ wrote:
Hello,

I don't understand how static and virtual pool's size related to thread's available working space.
I got the example app from the sel4-tutorials project with process creation (app-4).
A static pool and a virtual pool are created in this app. I have done experiments with size of this pools and size of arrays in the second thread.
For example I set size of virtual pool to zero, as I understand this pool need to create kernel objects. Also I define the test array size of (1 << 23)~8,3Mb.
If test array is static, static pool size must be equal to ((1 << seL4_PageBits) * 100) ~0,4Mb.
If test array is no static, static pool size not limited.
Why is it so?

--š
Best Regards,
Rinat Dobrokhotov

_______________________________________________
Devel mailing list
Devel@sel4.systems
https://sel4.systems/lists/listinfo/devel



The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.