From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756135AbdJJMbF (ORCPT ); Tue, 10 Oct 2017 08:31:05 -0400 Received: from mga11.intel.com ([192.55.52.93]:42218 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756058AbdJJMbD (ORCPT ); Tue, 10 Oct 2017 08:31:03 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,505,1500966000"; d="scan'208";a="1180521435" Subject: Re: [PATCH V8 00/14] mmc: Add Command Queue support To: Ulf Hansson Cc: linux-mmc , linux-block , linux-kernel , Bough Chen , Alex Lemberg , Mateusz Nowak , Yuliy Izrailov , Jaehoon Chung , Dong Aisheng , Das Asutosh , Zhangfei Gao , Sahitya Tummala , Harjani Ritesh , Venu Byravarasu , Linus Walleij , Shawn Lin , Christoph Hellwig References: <1505302814-19313-1-git-send-email-adrian.hunter@intel.com> <2cd4c5fc-cc04-ba44-bea6-4547d84de3e2@intel.com> From: Adrian Hunter Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki Message-ID: <9a789f9b-a8c4-8ae7-8f93-0d76f674bded@intel.com> Date: Tue, 10 Oct 2017 15:24:10 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/10/17 15:12, Ulf Hansson wrote: > On 21 September 2017 at 11:44, Adrian Hunter wrote: >> On 21/09/17 12:01, Ulf Hansson wrote: >>> On 13 September 2017 at 13:40, Adrian Hunter wrote: >>>> Hi >>>> >>>> Here is V8 of the hardware command queue patches without the software >>>> command queue patches, now using blk-mq and now with blk-mq support for >>>> non-CQE I/O. >>>> >>>> After the unacceptable debacle of the last release cycle, I expect an >>>> immediate response to these patches. >>>> >>>> HW CMDQ offers 25% - 50% better random multi-threaded I/O. I see a slight >>>> 2% drop in sequential read speed but no change to sequential write. >>>> >>>> Non-CQE blk-mq showed a 3% decrease in sequential read performance. This >>>> seemed to be coming from the inferior latency of running work items compared >>>> with a dedicated thread. Hacking blk-mq workqueue to be unbound reduced the >>>> performance degradation from 3% to 1%. >>>> >>>> While we should look at changing blk-mq to give better workqueue performance, >>>> a bigger gain is likely to be made by adding a new host API to enable the >>>> next already-prepared request to be issued directly from within ->done() >>>> callback of the current request. >>> >>> Adrian, I am reviewing this series, however let me comment on each >>> change individually. >>> >>> I have also run some test on my ux500 board and enabling the blkmq >>> path via the new MMC Kconfig option. My idea was to run some iozone >>> comparisons between the legacy path and the new blkmq path, but I just >>> couldn't get to that point because of the following errors. >>> >>> I am using a Kingston 4GB SDHC card, which is detected and mounted >>> nicely. However, when I decide to do some writes to the card I get the >>> following errors. >>> >>> root@ME:/mnt/sdcard dd if=/dev/zero of=testfile bs=8192 count=5000 conv=fsync >>> [ 463.714294] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>> [ 464.722656] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>> [ 466.081481] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>> [ 467.111236] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>> [ 468.669647] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>> [ 469.685699] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>> [ 471.043334] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>> [ 472.052337] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>> [ 473.342651] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>> [ 474.323760] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>> [ 475.544769] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>> [ 476.539031] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>> [ 477.748474] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>> [ 478.724182] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! >>> >>> I haven't yet got the point of investigating this any further, and >>> unfortunate I have a busy schedule with traveling next week. I will do >>> my best to look into this as soon as I can. >>> >>> Perhaps you have some ideas? >> >> The behaviour depends on whether you have MMC_CAP_WAIT_WHILE_BUSY. Try >> changing that and see if it makes a difference. > > Yes, it does! I disabled MMC_CAP_WAIT_WHILE_BUSY (and its > corresponding code in mmci.c) and the errors goes away. > > When I use MMC_CAP_WAIT_WHILE_BUSY I get these problems: > > [ 223.820983] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! > [ 224.815795] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! > [ 226.034881] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! > [ 227.112884] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! > [ 227.220275] mmc0: Card stuck in wrong state! mmcblk0 mmc_blk_card_stuck > [ 228.686798] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! > [ 229.892150] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! > [ 231.031890] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! > [ 232.239013] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer! > 5000+0 records in > 5000+0 records out > root@ME:/mnt/sdcard > > I looked at the new blkmq code from patch v10 13/15. It seems like the > MMC_CAP_WAIT_WHILE_BUSY is used to determine whether the async request > mechanism should be used or not. Perhaps I didn't looked close enough, > but maybe you could elaborate on why this seems to be the case!? MMC_CAP_WAIT_WHILE_BUSY is necessary because it means that a data transfer request has finished when the host controller calls mmc_request_done(). i.e. polling the card is not necessary. Have you tried V9 or V10. There was a fix in V9 related to calling ->post_req() which could mess up DMA. The other thing that could go wrong with DMA is if it cannot accept ->post_req() being called from mmc_request_done().