[dm-devel] dm: submit stacked requests in irq enabled context

[Neeraj Soni]

As of now i can not move to the latest stable version (4.11 is what i 
see in https://www.kernel.org/) since we do not have support available 
for that.

I assume that this patch will be present even in 4.11 so effectively if 
no remedy is brought in in 4.11 the problem will still exist since we 
are dealing with an additional thread and scheduling delays.

Neeraj

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

On 5/9/2017 9:25 PM, Keith Busch wrote:
> On Tue, May 09, 2017 at 03:19:31PM +0530, Neeraj Soni wrote:
>>     + Alasdair and dm-devel for awareness and inputs.
>>
>>     On 5/9/2017 12:26 PM, Neeraj Soni wrote:
>>
>>       Hi Keith/Snitzer,
>>
>>       I have recently started using kernel 4.4 on a Android device and ran
>>       Androbench to check storage read/write performance. I found that the
>>       Random Read (RR) and Random write(RW) performance with Full Disk
>>       Encryption is degraded compared to no Disk Encryption. Initially i
>>       thought this must the issue with the storage part used and i compared
>>       the performance of similar storage part on a device that was using
>>       Android with kernel 3.18. I found that with no Disk Encryption the
>>       performance was equivalent to the device which was using 4.4 but with
>>       Disk Encryption there was degradation in RR (~20%) and RW(10%).
>>
>>       I then tried to compare the changes that was brought in kernel 4.4 in
>>       Full Disk Encryption path. I came across the patch mentioned in subject
>>       and found that now a worker thread is scheduled in dm_request_fn() to
>>       process the requests instead of directly invoking map_request() as was
>>       in kernel 3.18.
>>
>>       I reverted this patch and found that the RR and RW performance was now
>>       closer to what we have without Disk Encryption. From the commit message
>>       i understand that this change is significant and will be required for
>>       blk-mq support but have you came across such degradation issue with your
>>       patch and do we have any fix for this degradation available?
> Just for comparison, could you check performance on a more recent stable
> kernel?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20170510/c5171897/attachment.htm>