> Maya Erez wrote:
>>
>> > + if (reqs >= 2) {
>> > + mmc_blk_packed_hdr_wrq_prep(mq->mqrq_cur, card, mq, reqs);
>> > + if (rq_data_dir(rqc) == READ) {
>> > + areq = &mq->mqrq_cur->mmc_active;
>> > + mmc_wait_for_req(card->host, areq->mrq);
>> Packing read requests requires preparation of two requests. After
>> sending
>> the header we wait for its completion before sending the next request
>> (mmc_wait_for_req is used). Therefore, if we try to pack 2 read requests
>> we might end up with worse performance in comparison to sending each
>> request by itself (which allows the preparation of one request while the
>> other is sent).
>> I suggest to check the size of the packed commands list and in case it
>> is
>> less than 3 send the requests one by one. If you move
>> mmc_blk_chk_packable
>> to queue.c after the first fetch this change should be very easy and can
>> be done by removing the requests from the packed_list and calling
>> issue_fn
>> for each one of them.
>
> Sending header for packed read which doesn't require nand program
> unlike normal data, so it may not spend long time.
> Which point you think is the overhead of packed two-requests
> in comparison to individual request?
When you send the packed commands you have to send an additional sector.
When you have only 2 or even 3 requests to send this might not be
negligible.
I think it's worth checking how often we send 2-3 requests in the packed
commands and if it's better to send it separately or packed. According to
the results you can decide if it's worth handling such cases.
Thanks,
Maya Erez
Consultant for 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
>
>
--
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
