On Tue, July 31, 2012 8:46 am, Jens Axboe wrote: > On 07/31/2012 04:36 PM, merez@xxxxxxxxxxxxxx wrote: >> Hi Jens, >> >> Do you have comments on this patch? >> Can we push it to kernel 3.6 version? > > I have questions - what is this good for? In other words, explain to me > why this is useful code. And in particular why this cannot be done from > userspace with bsg and block tracing? > > IOW, I'm dubious as to whether a new _io scheduler_ is the correct > solution to the problem you have at hand. > > -- > Jens Axboe > > The test scheduler allows us to control the dispatched requests and their order without an interfering of other requests. You can review the patches which depends on this patch in order to better understand how it is used. For example, in the eMMC4.5 packed commands feature, the MMC layer can pack read or write requests (the packed requests must be of the same direction). MMC layer will stop fetching the requests in case the packing conditions are broken. In order to test this feature we had to have a full control on the requests that the MMC layer fetches and their order, so that we will be able to determine if the expected behavior was actually achieved. The test-iosched can call specific block device callbacks, for example for checking the test results. Also, in order to be able to run out tests on the main eMMC card that runs in HS200, we cannot "shut down" the real FS requests, otherwise our phone won't come up or crash. The test-iosched allows us to delay the real FS requests until the end of the test, therefore the tests can be done on the main eMMC card. We chose not to use blocktrace due to the "real" FS requests interference in the middle of the test. I'm not familiar with bsg so I cannot tell if it can answer all the requirements I specified above. Thanks, Maya -- Sent by consultant of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
