@@ -1,35 +1,29 @@
-# Test Case 5 - Pseudocode
+Testcase 05
+-----------
-# This test looks for memory leaks or deadlocks
+It's been found that sometimes onlining and offlining CPUs confuse some
+of the various system tools. We found that sar wouldn't register the change
+in newly available cpus that weren't there when it started. This
+test case seeks to exercise this known error cases and verify that
+they behave correctly now.
-# "mm_struct slab leak (affected only some architectures)"
+Algorithm - Sar
+===============
+Given a CPU to test that exists
-INTERVAL=30
-THRESHHOLD='xxx'
+Make sure the specified cpu is offline
-# TODO: Start monitoring memory usage via vmstat and sar
+Loop until done:
+ Start up sar writing to a temp log and give it a little time to run
-# TODO: Start dbt2, running for at least 4 hours
+ Verify that SAR has correctly displayed all fields of CPU statistics
+ as '0.00' for the offlined CPU or just not displayed it in its tmp log
-while [ 1 ]; do
- last if workload has completed
+ Online the specified cpu
- select a cpu at random
- if cpu is online
- offline it
- else
- online it
- fi
+ Take another timestamp and another count of offlined CPUs
- measure current throughput
- # TODO: Mary and Mark will better define how to detect
- # the threshhold and what to do in response
- if [ throughput falls below $THRESHHOLD ]; then
- echo "Throughput has fallen below threshhold."
- fi
+ Verify SAR registered the change in CPU online/offline states
- sleep $INTERVAL
-done
-
-# Analyze system statistics to determine memory leaks
-# Analyze drops in activities
+When exiting:
+ Kill the sar process
@@ -2,11 +2,9 @@ Testcase 06
-----------
It's been found that sometimes onlining and offlining CPUs confuse some
-of the various system tools. In particular, we found it caused top to
-crash, and found that sar wouldn't register newly available cpus that
-weren't there when it started. This test case seeks to exercise these
-known error cases and verify that they behave correctly now.
-
+of the various system tools. We found it caused top to
+crash. This test case seeks to exercise this known error cases and
+verify that they behave correctly now.
Algorithm - Top
===============
@@ -29,28 +27,3 @@ When exiting:
Restore all CPUs to their initial state
-Algorithm - Sar
-===============
-Given a CPU to test that exists
-
-Make sure the specified cpu is offline
-
-Loop until done:
- Start up sar writing to a temp log and give it a little time to run
-
- Verify that SAR has correctly listed the missing CPU as 'nan' in its
- tmp log
-
- Take a timestamp and count how many CPUs sar is reporting to be
- offline
-
- Online the specified cpu
-
- Take another timestamp and another count of offlined CPUs.
-
- Verify that the number of CPUs offline has changed
-
-When exiting:
- Kill the sar process
-
-
The series of cpu_hotplug tests has changed a lot compared to its first version. However, the part of docs which briefly describe the test behavior are rarely updated correspondly. This could confuse people who want to read it when they use the test for the first time. Update the docs to make them useful. Signed-off-by: Yiwei Lin <s921975628@gmail.com> --- .../hotplug/cpu_hotplug/doc/hotplug05.txt | 46 ++++++++----------- .../hotplug/cpu_hotplug/doc/hotplug06.txt | 33 ++----------- 2 files changed, 23 insertions(+), 56 deletions(-)