From: Davidlohr Bueso <dave@stgolabs.net>
To: paulmck@linux.vnet.ibm.com
Cc: peterz@infradead.org, mingo@kernel.org,
linux-kernel@vger.kernel.org, dave@stgolabs.net,
Davidlohr Bueso <dbueso@suse.de>
Subject: [PATCH 2/9] locktorture: Add documentation
Date: Thu, 11 Sep 2014 20:40:17 -0700 [thread overview]
Message-ID: <1410493224-3312-3-git-send-email-dave@stgolabs.net> (raw)
In-Reply-To: <1410493224-3312-1-git-send-email-dave@stgolabs.net>
Just like Documentation/RCU/torture.txt, begin a document for the
locktorture module. This module is still pretty green, so I have
just added some specific sections to the doc (general desc, params,
usage, etc.). Further development should update the file.
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
---
Documentation/locking/locktorture.txt | 128 ++++++++++++++++++++++++++++++++++
1 file changed, 128 insertions(+)
create mode 100644 Documentation/locking/locktorture.txt
diff --git a/Documentation/locking/locktorture.txt b/Documentation/locking/locktorture.txt
new file mode 100644
index 0000000..c0ab969
--- /dev/null
+++ b/Documentation/locking/locktorture.txt
@@ -0,0 +1,128 @@
+Kernel Lock Torture Test Operation
+
+CONFIG_LOCK_TORTURE_TEST
+
+The CONFIG LOCK_TORTURE_TEST config option provides a kernel module
+that runs torture tests on core kernel locking primitives. The kernel
+module, 'locktorture', may be built after the fact on the running
+kernel to be tested, if desired. The tests periodically outputs status
+messages via printk(), which can be examined via the dmesg (perhaps
+grepping for "torture"). The test is started when the module is loaded,
+and stops when the module is unloaded. This program is based on how RCU
+is tortured, via rcutorture.
+
+This torture test consists of creating a number of kernel threads which
+acquires the lock and holds it for specific amount of time, thus simulating
+different critical region behaviors. The amount of contention on the lock
+can be simulated by either enlarging this critical region hold time and/or
+creating more kthreads.
+
+
+MODULE PARAMETERS
+
+This module has the following parameters:
+
+
+ ** Locktorture-specific **
+
+nwriters_stress Number of kernel threads that will stress exclusive lock
+ ownership (writers). The default value is twice the amount
+ of online CPUs.
+
+torture_type Type of lock to torture. By default, only spinlocks will
+ be tortured. This module can torture the following locks,
+ with string values as follows:
+
+ o "lock_busted": Simulates a buggy lock implementation.
+
+ o "spin_lock": spin_lock() and spin_unlock() pairs.
+
+ o "spin_lock_irq": spin_lock_irq() and spin_unlock_irq()
+ pairs.
+
+torture_runnable Start locktorture at module init. By default it will begin
+ once the module is loaded.
+
+
+ ** Torture-framework (RCU + locking) **
+
+shutdown_secs The number of seconds to run the test before terminating
+ the test and powering off the system. The default is
+ zero, which disables test termination and system shutdown.
+ This capability is useful for automated testing.
+
+onoff_holdoff The number of seconds between each attempt to execute a
+ randomly selected CPU-hotplug operation. Defaults to
+ zero, which disables CPU hotplugging. In HOTPLUG_CPU=n
+ kernels, locktorture will silently refuse to do any
+ CPU-hotplug operations regardless of what value is
+ specified for onoff_interval.
+
+onoff_holdoff The number of seconds to wait until starting CPU-hotplug
+ operations. This would normally only be used when
+ locktorture was built into the kernel and started
+ automatically at boot time, in which case it is useful
+ in order to avoid confusing boot-time code with CPUs
+ coming and going. This parameter is only useful if
+ CONFIG_HOTPLUG_CPU is enabled.
+
+stat_interval Number of seconds between statistics-related printk()s.
+ By default, locktorture will report stats every 60 seconds.
+ Setting the interval to zero causes the statistics to
+ be printed -only- when the module is unloaded, and this
+ is the default.
+
+stutter The length of time to run the test before pausing for this
+ same period of time. Defaults to "stutter=5", so as
+ to run and pause for (roughly) five-second intervals.
+ Specifying "stutter=0" causes the test to run continuously
+ without pausing, which is the old default behavior.
+
+shuffle_interval The number of seconds to keep the test threads affinitied
+ to a particular subset of the CPUs, defaults to 3 seconds.
+ Used in conjunction with test_no_idle_hz.
+
+verbose Enable verbose debugging printking, via printk(). Enabled
+ by default. This extra information is mostly related to
+ high-level errors and reports from the main 'torture'
+ framework.
+
+
+STATISTICS
+
+Statistics are printed in the following format:
+
+spin_lock-torture: Writes: Total: 93746064 Max/Min: 0/0 Fail: 0
+ (A) (B) (C) (D)
+
+(A): Lock type that is being tortured -- torture_type parameter.
+
+(B): Number of times the lock was acquired.
+
+(C): Min and max number of times threads failed to acquire the lock.
+
+(D): true/false values if there were errors acquiring the lock. This should
+ -only- be positive if there is a bug in the locking primitive's
+ implementation. Otherwise a lock should never fail (ie: spin_lock()).
+ Of course, the same applies for (C), above. A dummy example of this is
+ the "lock_busted" type.
+
+USAGE
+
+The following script may be used to torture locks:
+
+ #!/bin/sh
+
+ modprobe locktorture
+ sleep 3600
+ rmmod locktorture
+ dmesg | grep torture:
+
+The output can be manually inspected for the error flag of "!!!".
+One could of course create a more elaborate script that automatically
+checked for such errors. The "rmmod" command forces a "SUCCESS",
+"FAILURE", or "RCU_HOTPLUG" indication to be printk()ed. The first
+two are self-explanatory, while the last indicates that while there
+were no locking failures, CPU-hotplug problems were detected.
+
+Also see: Documentation/RCU/torture.txt
--
1.8.4.5
next prev parent reply other threads:[~2014-09-12 3:41 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-12 3:40 [PATCH -tip 0/9] locktorture: Improve and expand lock torturing Davidlohr Bueso
2014-09-12 3:40 ` [PATCH 1/9] locktorture: Rename locktorture_runnable parameter Davidlohr Bueso
2014-09-12 17:40 ` Paul E. McKenney
2014-09-12 17:51 ` Paul E. McKenney
2014-09-12 3:40 ` Davidlohr Bueso [this message]
2014-09-12 5:28 ` [PATCH 2/9] locktorture: Add documentation Davidlohr Bueso
2014-09-13 1:10 ` Randy Dunlap
2014-09-16 19:35 ` Paul E. McKenney
2014-09-12 3:40 ` [PATCH 3/9] locktorture: Support mutexes Davidlohr Bueso
2014-09-12 18:02 ` Paul E. McKenney
2014-09-12 18:56 ` Davidlohr Bueso
2014-09-12 19:12 ` Paul E. McKenney
2014-09-13 2:13 ` Davidlohr Bueso
2014-09-12 3:40 ` [PATCH 4/9] locktorture: Teach about lock debugging Davidlohr Bueso
2014-09-12 3:40 ` [PATCH 5/9] locktorture: Make statistics generic Davidlohr Bueso
2014-09-12 3:40 ` [PATCH 6/9] torture: Address race in module cleanup Davidlohr Bueso
2014-09-12 18:04 ` Paul E. McKenney
2014-09-12 18:28 ` Davidlohr Bueso
2014-09-12 19:03 ` Paul E. McKenney
2014-09-12 4:40 ` [PATCH 7/9] locktorture: Add infrastructure for torturing read locks Davidlohr Bueso
2014-09-12 16:06 ` Paul E. McKenney
2014-09-12 18:02 ` Davidlohr Bueso
2014-09-12 4:41 ` [PATCH 8/9] locktorture: Support rwsems Davidlohr Bueso
2014-09-12 7:37 ` Peter Zijlstra
2014-09-12 14:49 ` Davidlohr Bueso
2014-09-12 18:07 ` Paul E. McKenney
2014-09-12 4:42 ` [PATCH 9/9] locktorture: Introduce torture context Davidlohr Bueso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1410493224-3312-3-git-send-email-dave@stgolabs.net \
--to=dave@stgolabs.net \
--cc=dbueso@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®