On Thu, Jun 7, 2012 at 1:14 AM, Maya Erez <[email protected]> wrote:
> The test scheduler allows testing a block device by dispatching
> specific requests according to the test case and declare PASS/FAIL
> according to the requests completion error code
>
I can't get the point. Isn't this possible purely from userspace using IOCTLs ?
Even otherwise, requiring to modify the scheduler for each test case
is definitely not scalable.
> Changes in v2:
> ? ?- Export test-iosched functionality to allow definition of the block device
> ? ? ?tests under the block device layer
> ? ?- Add registration of block device tests utilities
>
> Maya Erez (1):
> ?block: Add test-iosched scheduler
>
> ?Documentation/block/test-iosched.txt | ? 39 ++
> ?block/Kconfig.iosched ? ? ? ? ? ? ? ?| ? ?8 +
> ?block/Makefile ? ? ? ? ? ? ? ? ? ? ? | ? ?1 +
> ?block/blk-core.c ? ? ? ? ? ? ? ? ? ? | ? ?3 +-
> ?block/test-iosched.c ? ? ? ? ? ? ? ? | 1025 ++++++++++++++++++++++++++++++++++
> ?include/linux/test-iosched.h ? ? ? ? | ?218 +++++++
> ?6 files changed, 1292 insertions(+), 2 deletions(-)
> ?create mode 100644 Documentation/block/test-iosched.txt
> ?create mode 100644 block/test-iosched.c
> ?create mode 100644 include/linux/test-iosched.h
>
> On Thu, Jun 7, 2012 at 1:14 AM, Maya Erez <[email protected]> wrote:
>> The test scheduler allows testing a block device by dispatching
>> specific requests according to the test case and declare PASS/FAIL
>> according to the requests completion error code
>>
> I can't get the point. Isn't this possible purely from userspace using
> IOCTLs ?
> Even otherwise, requiring to modify the scheduler for each test case
> is definitely not scalable.
The main benefit of the test-iosched is the ability to determine the
timing of each request that is being dispatched and to put on hold the
real FS requests so that they won't affect the tests scenario.
It also allows each block device to determine pass/fail result taking into
account the expected behavior and the actual result.
The scheduler doesn't have to be changed per tests case. What made you
think it should be?
Currently we use the test-iosched to test the eMMC4.5 features (such as
BKOPs, packed commands and sanitize). I hope that after we will release
the tests later this week it will be clearer.
>
>> Changes in v2:
>> ? ?- Export test-iosched functionality to allow definition of the block
>> device
>> ? ? ?tests under the block device layer
>> ? ?- Add registration of block device tests utilities
>>
>> Maya Erez (1):
>> ?block: Add test-iosched scheduler
>>
>> ?Documentation/block/test-iosched.txt | ? 39 ++
>> ?block/Kconfig.iosched ? ? ? ? ? ? ? ?| ? ?8 +
>> ?block/Makefile ? ? ? ? ? ? ? ? ? ? ? | ? ?1 +
>> ?block/blk-core.c ? ? ? ? ? ? ? ? ? ? | ? ?3 +-
>> ?block/test-iosched.c ? ? ? ? ? ? ? ? | 1025
>> ++++++++++++++++++++++++++++++++++
>> ?include/linux/test-iosched.h ? ? ? ? | ?218 +++++++
>> ?6 files changed, 1292 insertions(+), 2 deletions(-)
>> ?create mode 100644 Documentation/block/test-iosched.txt
>> ?create mode 100644 block/test-iosched.c
>> ?create mode 100644 include/linux/test-iosched.h
>>
>
Thanks,
Maya Erez
Consultant for Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
On Sat, Jun 9, 2012 at 8:24 PM, <[email protected]> wrote:
>
>> On Thu, Jun 7, 2012 at 1:14 AM, Maya Erez <[email protected]> wrote:
>>> The test scheduler allows testing a block device by dispatching
>>> specific requests according to the test case and declare PASS/FAIL
>>> according to the requests completion error code
>>>
>> I can't get the point. Isn't this possible purely from userspace using
>> IOCTLs ?
>> Even otherwise, requiring to modify the scheduler for each test case
>> is definitely not scalable.
> The main benefit of the test-iosched is the ability to determine the
> timing of each request that is being dispatched and to put on hold the
> real FS requests so that they won't affect the tests scenario.
Then a potentially long running test can block any useful work that can
be done on the device. no-op is not the right scheduler for the example
you mentioned (eMMC), so such device has to be mounted only for the
purpose of running the tests.
So using standard noop + debugfs would be sufficient for 99% of the cases ?
> It also allows each block device to determine pass/fail result taking into
> account the expected behavior and the actual result.
> The scheduler doesn't have to be changed per tests case. What made you
> think it should be?
Err.. I misread this section of documentation. I read is as sysfs
instead of debugfs.
My mistake..
<Quote>
+Each test is exposed via debugfs and can be triggered by writing to
+the debugfs file. In order to add a new test one should expose a new debugfs
+file for the new test.
</Quote>
> Currently we use the test-iosched to test the eMMC4.5 features (such as
> BKOPs, packed commands and sanitize). I hope that after we will release
> the tests later this week it will be clearer.
>>
Sure. It'd be useful.