tock / elf2tab

Tool to create Tock Application Bundles from ELF files.
MIT License
15 stars 33 forks source link

Does --kernel-heap flag create redundant/wasted space in RAM? #52

Closed reynoldsbd closed 2 years ago

reynoldsbd commented 2 years ago

I'm trying to infer the purpose of the --kernel-heap flag.

Mechanically, the behavior of this flag seems simple: it reserves additional RAM space for an application separately from its stack/data/heap sections.

Ostensibly, this extra reservation is intended to be used by the kernel rather than being accessible to the app itself. Is the intent that this space is used for grants and other per-process data structures?

I also notice that there is some logic inside the kernel's process loader to reserve extra RAM for kernel data structures:

https://github.com/tock/tock/blob/64cc04c67e578eb9c6c3d44a9ea71a42d5c18892/kernel/src/process_standard.rs#L1378-L1382

To me, it seems like we are allocating space for per-process kernel data twice: once in the kernel, and again in elf2tab. Is this correct? Or (more likely) am I misinterpreting the purpose of --kernel-heap?

bradjc commented 2 years ago

Is the intent that this space is used for grants and other per-process data structures?

Maybe. It is used for grants. It could be for per-process data structures, but not necessarily all per-process data structures.

To me, it seems like we are allocating space for per-process kernel data twice: once in the kernel, and again in elf2tab. Is this correct?

Yes, this is correct.

We use "grant" somewhat loosely. In practice it means anything that is kernel owned and only accessible by the kernel, but stored in the process's memory region. So we do both to set the grant space. --kernel-heap specifies the requested size for the dynamically allocated grants created as a process runs and uses capsules. The calculation in process_standard.rs is for the fixed overhead to store the ProcessStandard object itself as well as the table to keep track of the dynamically allocated grants. The idea is that a process has some idea of how many grants will be allocated as it runs. However, it shouldn't have to know the size of the ProcessStandard object.

One way to think about this is --kernel-heap is intended to set the size of the grant region that will be used after the process has started executing. That is, the space that is only known by the process as the space needed is dependent on what the process actually does.

reynoldsbd commented 2 years ago

Thanks for the explanation!

a process has some idea of how many grants will be allocated...

This is probably documented somewhere, but are the sizes of grants architecture-independent?

bradjc commented 2 years ago

This is probably documented somewhere, but are the sizes of grants architecture-independent?

I believe that because Tock is only on 32 bit platforms the size of the grant is in fact architecture/board/platform independent. However, we don't have any stability guarantees on the size of each grant from kernel version to kernel version. This is definitely a weakness for app reliability as the kernel changes. We've only recently started talking about this, and our first attempt of including --kernel-heap in elf2tab is probably not the approach we want to stick with long-term.

reynoldsbd commented 2 years ago

Perhaps something similar to the "permissions" section of TBFv2: apps declare which drivers they intend to use, and the kernel uses that information to compute the space required for grants