Difference between revisions of "Containers/UBC discussion"

From OpenVZ Virtuozzo Containers Wiki
Jump to: navigation, search
(best cat supplements)
m (Reverted edits by 199.15.234.8 (Talk) to last revision by Kir)
Line 1: Line 1:
INSERT
+
== 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 08:03, 19 January 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?