Kernel Project/Memory Pools

Memory pools are a means for system integrators to specify fine grained memory layout. The hope is that they would also support cache partitioning.

In addition to general ability of applications to explicitly control their memory layout, the mechanism below uses a specification based on ELF file format to specify which pool segments of an ELF image are to come from. This solves two problems:

1. Shared code using a pool.
2. Specific processes needing to allocate RAM at a fine grain from various pools (e.g., each segment of an executable).

 memoryPoolNames vector of <"name", memoryPoolsIndex>
 memoryPools vector of <start addr, length, stripe, step, caching attribute?, bit testable>

1. Each process must have quota for each pool.
2. Each process has a "current" memory pool where allocations come from.
3. Deallocation always goes back to the correct pool.

Hyperstart needs a "system pool" which defines where hyperstart allocates RAM from (kernel data, bss and checksummers).

Registry specifies all of the pools available (ala memoryPools and memoryPoolNames). The "system pool" specification from the hyperstart takes precedence. Each pool must be initialized at kernel coldstart.

Checksummer is being removed.

For each process template, the registry specifies a list of "File Mapping Information":

• executable name, i.e., image loadable file name.
• vector of <pool #> indexed by segment #
• file default pool

The resulting pool for each mapped file segment is specified by the following table.

filename Match	segment in list	segment Writable	Execute from ram	Resulting pool
N	NA	N	N	Where ever the file happens to be stored
N	NA	N	Y	Thread current pool (at process creation the process's default pool is used)
N	NA	Y	DC	Thread current pool (at process creation the process's default pool is used)
Y	N	DC	DC	File Default pool
Y	Y	DC	DC	File Segment Vector pool

runtime mapping each ELF file:

• Each segment would be mapped as
  • save current memory pool (thread local);
  • setMemoryPool(lookup entry from registry)
  • map the segment/allocate ram
  • restore memory pool;

AL: Ryan, what is this? I thought we were going to handle the kernel via the segment mapping table.

• The Kernel heap pool name

AL: Current plan is system cache table is Not Implemented
File system cache table is like the table above, but specifies actions to take place at system startup At kernel startup we the "file system cache table" is defined:

1. Thaw "PIB list".
2. For each file in the table, "thaw" the specified segment and update the file VAS.
3. Update PIB with new file PDT.

Kernel APIs to set/get thread local value for current memory pool:

setRamQuotaPoolIndex() Registry specifies default.
getRamQuotaPoolIndex() All memory allocation comes from the specified memory pool.

Issues

Should we put the init-only portions of kernel and the copies of the exception vectors outside the above?