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