blob: 75d813418c0002c4063716680b2d1c33a9a4eb6b [file] [log] [blame]
Maya Erez60181552012-06-27 11:25:26 +03001Test IO scheduler
2==================
3
4The test scheduler allows testing a block device by dispatching
5specific requests according to the test case and declare PASS/FAIL
6according to the requests completion error code.
7
8The test IO scheduler implements the no-op scheduler operations, and uses
9them in order to dispatch the non-test requests when no test is running.
10This will allow to keep a normal FS operation in parallel to the test
11capability.
12The test IO scheduler keeps two different queues, one for real-world requests
13(inserted by the FS) and the other for the test requests.
14The test IO scheduler chooses the queue for dispatch requests according to the
15test state (IDLE/RUNNING).
16
17the test IO scheduler is compiled by default as a dynamic module and enabled
18only if CONFIG_DEBUG_FS is defined.
19
20Each block device test utility that would like to use the test-iosched test
21services, should register as a blk_dev_test_type and supply an init and exit
22callbacks. Those callback are called upon selection (or removal) of the
23test-iosched as the active scheduler. From that point the block device test
24can start a test and supply its own callbacks for preparing, running, result
25checking and cleanup of the test.
26
27Each test is exposed via debugfs and can be triggered by writing to
28the debugfs file. In order to add a new test one should expose a new debugfs
29file for the new test.
30
31Selecting IO schedulers
32-----------------------
33Refer to Documentation/block/switching-sched.txt for information on
34selecting an io scheduler on a per-device basis.
35
36
37May 10 2012, maya Erez <merez@codeaurora.org>
38
39