Containers/UBC discussion

Agreement list

Here we put design features that everyone agree

• resources are:
  • kernel memory
  • total length of unreclaimable mappings
  • physical pages
• each resource group is independent from each other

unified interface for mem, cpu, disk I/O

It is still not clear whether we need unified interface.

Having one syscall for setting values for different resources seems OK if leaving alone the meaning of the "value" notion.

memory reclamation

Pending to be implemented on top of BC.

moving tasks across beancounters

Required changes:

1. saving bc on vma instead of mm
2. can two threads in a process be in different BC contexts?
3. changing mm->bc in set_bc_id().

what is implied by the term "guarantee"

1. container will be able to touch that number of pages - I think this one (Hansendc)
2. container will be able to map that number of pages
3. container will not be killed unless it touches that number of pages
4. anything else

make it possible to charge full user page to its allocator and keep it charged till unmapped

Consider creating resource groups via the use of aggregation (aggregated BC)

Top Level Design - thoughts on how to accomplish the goal

1. Create a BC per thread group
2. Associate a group of BC's with an aggregated BC (we can call this a BC resource group)
3. Enable migration of tasks by charging and un-charging aggregated BC when a BC moves across from one aggregated BC to another
4. Change set_bcid() to create aggregated BC's instead of BC's

Accounting information

1. Is it possible to merge vm_acct_memory() with the accounting information in beancounters?