On Tue, July 31, 2012 8:46 am, Jens Axboe wrote:
> On 07/31/2012 04:36 PM, [email protected] 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
Hi Jens,
Can you refer to my reply?
Currently the test-iosched is our only option for testing the eMMC4.5
features on a HS200 eMMC card.
Thanks,
Maya
On Thu, August 2, 2012 6:16 am, [email protected] wrote:
>
> On Tue, July 31, 2012 8:46 am, Jens Axboe wrote:
>> On 07/31/2012 04:36 PM, [email protected] 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
>
>
--
Sent by consultant of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum