|
|
Line 1: |
Line 1: |
− | == Agreement list ==
| + | INSERT |
− | 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:
| |
− | # saving bc on vma instead of mm
| |
− | # can two threads in a process be in different BC contexts?
| |
− | # changing mm->bc in set_bc_id().
| |
− | | |
− | ; what is implied by the term "guarantee"
| |
− | # container will be able to touch that number of pages - I think this one (Hansendc)
| |
− | # container will be able to map that number of pages
| |
− | # container will not be killed unless it touches that number of pages
| |
− | # 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 ==
| |
− | # Create a BC per thread group
| |
− | # Associate a group of BC's with an aggregated BC (we can call this a BC resource group)
| |
− | # Enable migration of tasks by charging and un-charging aggregated BC when a BC moves across from one aggregated BC to another
| |
− | # Change set_bcid() to create aggregated BC's instead of BC's
| |
− | | |
− | == Accounting information ==
| |
− | # Is it possible to merge vm_acct_memory() with the accounting information in beancounters?
| |
− | | |
− | [[Category:UBC]]
| |
− | [[Category:Containers]]
| |