Difference between revisions of "Containers/UBC discussion"

From OpenVZ Virtuozzo Containers Wiki
Jump to: navigation, search
(minor reformatting)
(added to UBC category)
Line 27: Line 27:
 
# Enable migration of tasks by charging and un-charging aggregated BC when a BC moves across from one aggregated BC to another
 
# 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
 
# Change set_bcid() to create aggregated BC's instead of BC's
 +
 +
 +
[[Category:UBC]]

Revision as of 07:06, 14 September 2006

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