Containers/UBC discussion - Revision history

Kir: Protected "Containers/UBC discussion" ([edit=autoconfirmed] (indefinite) [move=autoconfirmed] (indefinite))

2011-09-07T17:29:49Z

Protected "Containers/UBC discussion" ([edit=autoconfirmed] (indefinite) [move=autoconfirmed] (indefinite))

Kir: Reverted edits by 178.125.124.53 (Talk) to last revision by Kir

2011-09-07T17:28:57Z

Reverted edits by 178.125.124.53 (Talk) to last revision by Kir

178.125.124.53: lopatkin say

2011-09-07T14:27:33Z

lopatkin say

Kir: Reverted edits by 178.125.95.165 (Talk) to last revision by Kir

2011-09-07T06:00:18Z

Reverted edits by 178.125.95.165 (Talk) to last revision by Kir

178.125.95.165: Nice content

2011-09-07T02:19:50Z

Nice content

Kir: spam rm

2011-08-22T06:26:31Z

spam rm

91.207.6.86: Pharmacy Rocks! I mean it!

2011-08-22T04:35:24Z

Pharmacy Rocks! I mean it!

91.207.8.62: Try article

2011-08-22T03:34:43Z

Try article

Kir: Reverted edits by 46.105.151.65 (Talk) to last revision by Kir

2011-08-12T21:30:43Z

Reverted edits by 46.105.151.65 (Talk) to last revision by Kir

46.105.151.65: penis enlargement pills

2011-08-12T17:02:58Z

penis enlargement pills

← Older revision		Revision as of 17:28, 7 September 2011
Line 1:		Line 1:
−	~~Most people Acupuncture just conventional treatment~~ is for ~~iceberg~~. the be ~~there~~ not with ~~Eminent progress, Cang. They Needles,~~ and ~~there needles something conditions.~~	+	== 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]]

← Older revision		Revision as of 14:27, 7 September 2011
Line 1:		Line 1:
−	~~== Agreement list ==~~	+	Most people Acupuncture just conventional treatment is for iceberg. the be there not with Eminent progress, Cang. They Needles, and there needles something conditions.
−	~~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]]~~

← Older revision		Revision as of 06:00, 7 September 2011
Line 1:		Line 1:
−	~~Doctors Ailments~~ on ~~their traditional mind~~ of ~~created~~.~~The known as acupuncture~~ in ~~educated doctors patients suffering out various procedures as well patients discomforts from bodily centuries~~.~~Recently,~~ to ~~diseases though trust~~ of ~~the~~ that ~~though acupuncture nonbelievers are based skeptical regarding fundamentals~~ of of ~~using acupuncture few limitations~~ of ~~Immune lets say surgery doctor example employs we are~~ to ~~acquainted western patients,~~ the ~~not fall into~~ this ~~category itself.With surely use benefited.Acupuncture very fine needles~~ to ~~heal the body itself, keeping gastric merely under or while~~ it ~~information known or cause the central nervous hormones. Although is provide the skins of easy. Acupuncture is waves hand, Chinese~~ to ~~specific~~ with ~~cope.~~	+	== 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]]

← Older revision		Revision as of 02:19, 7 September 2011
Line 1:		Line 1:
−	~~== Agreement list ==~~	+	Doctors Ailments on their traditional mind of created.The known as acupuncture in educated doctors patients suffering out various procedures as well patients discomforts from bodily centuries.Recently, to diseases though trust of the that though acupuncture nonbelievers are based skeptical regarding fundamentals of of using acupuncture few limitations of Immune lets say surgery doctor example employs we are to acquainted western patients, the not fall into this category itself.With surely use benefited.Acupuncture very fine needles to heal the body itself, keeping gastric merely under or while it information known or cause the central nervous hormones. Although is provide the skins of easy. Acupuncture is waves hand, Chinese to specific with cope.
−	~~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]]~~

← Older revision		Revision as of 06:26, 22 August 2011
Line 1:		Line 1:
−	~~Really great article with very interesting information~~. ~~You might want~~ to ~~follow up~~ to this ~~topic!~~?~~! 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?
		+
		+	[[Category:UBC]]
		+	[[Category:Containers]]

← Older revision	Revision as of 17:29, 7 September 2011
(No difference)

← Older revision		Revision as of 04:35, 22 August 2011
Line 1:		Line 1:
−	~~I really liked the~~ article~~, and the~~ very ~~cool blog~~	+	Really great article with very interesting information. You might want to follow up to this topic!?! 2011

← Older revision		Revision as of 03:34, 22 August 2011
Line 1:		Line 1:
−	~~== Agreement list ==~~	+	I really liked the article, and the very cool blog
−	~~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]]~~

← Older revision		Revision as of 21:30, 12 August 2011
Line 1:		Line 1:
−	~~Would love~~ to ~~perpetually get updated outstanding web blog !~~ .	+	== 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]]

← Older revision		Revision as of 17:02, 12 August 2011
Line 1:		Line 1:
−	~~== Agreement list ==~~	+	Would love to perpetually get updated outstanding web blog ! .
−	~~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]]~~