Difference between revisions of "Containers/UBC discussion"

From OpenVZ Virtuozzo Containers Wiki
Jump to: navigation, search
(New feature - remove sharing)
m (Protected "Containers/UBC discussion" ([edit=autoconfirmed] (indefinite) [move=autoconfirmed] (indefinite)))
 
(31 intermediate revisions by 14 users not shown)
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
 
; unified interface for mem, cpu, disk I/O
 
: It is still not clear whether we need unified interface.
 
: It is still not clear whether we need unified interface.
Line 19: Line 27:
  
 
; make it possible to charge full user page to its allocator and keep it charged till unmapped
 
; 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]]

Latest revision as of 17:29, 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:
  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?