Difference between revisions of "Containers/UBC discussion"
(lopatkin say) |
m (Reverted edits by 178.125.124.53 (Talk) to last revision by Kir) |
||
| Line 1: | Line 1: | ||
| − | + | == 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: | ||
| + | # 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]] | ||
Revision as of 17:28, 7 September 2011
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:
- 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?
