Difference between revisions of "VSwap testing"

From OpenVZ Virtuozzo Containers Wiki
Jump to: navigation, search
(added a header)
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
−
This article describes 4th generation resource management, to be used in Virtuozzo 7.
+
This article describes how to test [[VSwap]] functionality
  
−
{{Virtuozzo}}
+
[originally written by xemul@]
−
 
 
−
== Introduction ==
 
−
 
 
−
Each container is assigned RAM and SWAP limits. When a container hits
 
−
the RAM limit a (slow) swapout starts. When it hits the SWAP limit an
 
−
OOM killer is invoked for that container.
 
−
 
 
−
Note, that when a container hits its RAM limit, but there is enough RAM
 
−
on the host pages do not go to *real* swap, but instead are cached in
 
−
host RAM. Real swapout starts when there is no more real RAM. The same
 
−
is fair for FS page cache - clean cache pages are moved to the host RAM
 
−
instead of being dropped when a container hits its RAM limit so that no
 
−
pagein will happen on the next read provided there is enough free RAM on
 
−
the host.
 
−
 
 
−
The base functionality will be available in
 
−
 
 
−
* vzkernel-3.10.0-123.1.2.vz7.5.17
 
−
* vcmmd-7.0.6
 
−
 
 
−
== How to test ==
 
−
 
 
−
[originally written by xemul@ for vswap]
 
  
 
We need the following set of atomic tests
 
We need the following set of atomic tests
Line 83: Line 60:
  
 
6) No leaks happen after container stop. This will be done using kmemleak - see PSBM-34183
 
6) No leaks happen after container stop. This will be done using kmemleak - see PSBM-34183
−
 
−
More details will come later.
 
  
 
[[Category: QA]]
 
[[Category: QA]]

Latest revision as of 21:02, 2 July 2015

This article describes how to test VSwap functionality

[originally written by xemul@]

We need the following set of atomic tests

  • RAM limit works
  • SWAP limit works
  • OOM killer works
  • Pages sent to swap can be read back again
  • No real swapout starts when there's enough RAM on the node
  • No leaks happen after container stop

To do this the following set of atomic tests is required: 1) RAM limit works

  • Start container with unlimited RAM and SWAP.
  • Note the physpages.held value
  • Set RAM = physpages.held + X
  • Run memeater, that will map and touch RAM pages
  • _Before_ memeater exits check, that physpages.held didn't grow above the .limit

2) SWAP limit works

  • Start container with unlimited RAM and SWAP.
  • Note the physpages.held value
  • Set RAM = physpages.held + X
  • Set SWAP = Y
  • Run memeater, that will map and touch RAM + SWAP pages
  • Check that none of physpages.held and swappages.held grew above the .limit (memeater _may_ be killed during this test)

3) OOM killer works

  • Start two containers with unlimited RAM and SWAP
  • Set RAM and SWAP for both like in previous examples
  • Run memeater in one of them, that consumes infinite amount of RAM.
  • Check, that memeater is killed in the 1st container
  • Check, that no tasks in the 2nd one are killed

(the above three can probably be made of vzt-slm test) 4) Pages sent to swap can be read back again

  • Start container with unlimited RAM and SWAP.
  • Note the physpages.held value
  • Set RAM = physpages.held + X
  • Run memeater, that will map and write to 2xRAM pages
  • Check, that swappages.held is not zero
  • Make memeater read the whole memory again and check that the values written are preserved

5) No real swapout starts when there's enough RAM on the node

  • Take a node with non-zero swap partition
  • Start a container with unlimited RAM and SWAP
  • Note the physpages.held value
  • Check that real swap is not used
  • Set RAM = physpages.held + X
  • Run memeater, that will eat 2xRAM pages
  • Check, that memeater is not dead
  • Before memeater exits check, that swappages.held is not zero
  • Check that real swap is still not used

6) No leaks happen after container stop. This will be done using kmemleak - see PSBM-34183