From patchwork Thu Oct 26 12:57:45 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 117221 Delivered-To: patch@linaro.org Received: by 10.140.22.164 with SMTP id 33csp733087qgn; Thu, 26 Oct 2017 05:58:14 -0700 (PDT) X-Google-Smtp-Source: ABhQp+RdMywRgBcV0h2vSs3OIGIFl+azDqmvZS3j4ZhpO0XbuPEEkOYtpvXYllHqnpipISRgNORG X-Received: by 10.98.80.21 with SMTP id e21mr5383683pfb.208.1509022694854; Thu, 26 Oct 2017 05:58:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1509022694; cv=none; d=google.com; s=arc-20160816; b=HQDpHb6uGmbnHe8CdJBAhWnfyXsRC5rBWs0OlRUIFSBaEvycHzWw+sqRs1h2bylOMY FY+rqGq1VMlpQWVoJH9IrMx4eD9ny1UBSE+ZM+EKlfzBODYHG0BgwMRNzkNqgIl8Ynxt fdXMu/d/Bi69p3xF30ZdLpWycp8XyYJtXAeLOdJWoN9nWQ/li+X/13FzwqmehbwzM4Je 3F1+b4F5Gqo9CnK9mZc2dmpmasuYoT6PVW55A+cgIrgbsY+sABLSVXKC3/uO7NblLeWz bLSO/KgtLiVVMj/RKm5iESARjbQ2L7Y4/sxjRYbSOLSWK9OYJ18ZjSwl2ACeUQROG0Vj dHVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=A/crTD/bMBMO5D5hFidR711RFl+sMs6pcC3wU754knM=; b=0VRlHYls3IcQ6kqFCgNEhxy0QXdVE0txOasCWuWf3FOs2fyAo1A8T++v8mC4GJzNnc aPaF9HlRyWqfmdxQsJ38GYM7KQrG9NUhFQ4PIUP74kgI4fp57gPb34uPfEgGvcpDElOp uZLgIenMu4hlL54ZMEQOKvnj/7zC2i71Ojpl4bINOuWHsIv89JZsTgL76EMQxGn2TOMs JrV3eEqkACF3sXq21+LOxjytmttHvPsFg12+VT1VLU1iqKKJbKKmHmcaABCnfP3mZAcc On6M1JJvQ9uENJUQOO8k9ZO4OLbswsrkV7EXKAbJJAdBcND/w/79klsDNjgiRxaBwxmv Dq3A== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org header.s=google header.b=gS0S4kTb; spf=pass (google.com: best guess record for domain of linux-mmc-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-mmc-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y1si3605289pff.367.2017.10.26.05.58.14; Thu, 26 Oct 2017 05:58:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-mmc-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org header.s=google header.b=gS0S4kTb; spf=pass (google.com: best guess record for domain of linux-mmc-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-mmc-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932204AbdJZM6N (ORCPT + 6 others); Thu, 26 Oct 2017 08:58:13 -0400 Received: from mail-lf0-f65.google.com ([209.85.215.65]:56665 "EHLO mail-lf0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932375AbdJZM6H (ORCPT ); Thu, 26 Oct 2017 08:58:07 -0400 Received: by mail-lf0-f65.google.com with SMTP id 90so3622332lfs.13 for ; Thu, 26 Oct 2017 05:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=FP0iDY9ss7GrfUiZTGA9ArB83TmogspFgHzYuPuNE08=; b=gS0S4kTbUWI+aqsbd56bHKxO2rwE6SzpsF5VLWv09qzAkOdMq1IwotmcgXuL2uQ2MD ZAwLE9NIyRuwKVW6MJEHzBEwPiNTB5GtljTbY7A0MQFY7srHM+ybaHSeJhG2OM3hCJHE ak+WKVVfP3GScnpuXfQULLdUjuHvXrEJWnV48= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=FP0iDY9ss7GrfUiZTGA9ArB83TmogspFgHzYuPuNE08=; b=TixMo5xdusX12xY3ehP5KO0GcNBoxVAnYgv9Z21Q1Jz5f6duCGzRypZS6v1V0KVxr9 rVh/4Gv3DCmg8nr8lsuTdqZq7fvHVqdTGmPN6ATQTKgGGAzkWfaFgsqjGJT8er4aQh4I SN9RD0XGvZA3dIgeCOUQqZjcv/ythXVQmdo2xoR1BxsngK92SLOVihLAukIm3pkITPWy AIIfBrhpj4fzNdHGGqP3Xy3reKO/rc+urpIwIHHOFzH1HQGmJZWF6tuoYMeofFu7E5JB 3voZc/gsbgv+v+x9h7DpGc/AOVtSs3Pm6XNy4hGUfHu7FM3zSpnV1mANElyjsYbj6jnh Y4Dw== X-Gm-Message-State: AMCzsaWC8j+FsJkvxSjf2r2gEIQSOCaWOxbVQmM99C9Q2b7UNNMqmX61 2IkaPwGKcnuLTLj8v6IHUyg38nqMfiE= X-Received: by 10.25.43.9 with SMTP id r9mr7521698lfr.128.1509022685245; Thu, 26 Oct 2017 05:58:05 -0700 (PDT) Received: from genomnajs.ideon.se ([85.235.10.227]) by smtp.gmail.com with ESMTPSA id 34sm1165600lfr.25.2017.10.26.05.58.03 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 26 Oct 2017 05:58:04 -0700 (PDT) From: Linus Walleij To: linux-mmc@vger.kernel.org, Ulf Hansson Cc: linux-block@vger.kernel.org, Jens Axboe , Christoph Hellwig , Arnd Bergmann , Bartlomiej Zolnierkiewicz , Paolo Valente , Avri Altman , Adrian Hunter , Linus Walleij Subject: [PATCH 00/12 v4] multiqueue for MMC/SD Date: Thu, 26 Oct 2017 14:57:45 +0200 Message-Id: <20171026125757.10200-1-linus.walleij@linaro.org> X-Mailer: git-send-email 2.13.6 Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org This switches the MMC/SD stack over to unconditionally using the multiqueue block interface for block access. This modernizes the MMC/SD stack and makes it possible to enable BFQ scheduling on these single-queue devices. This is the v4 version of this v3 patch set from february: https://marc.info/?l=linux-mmc&m=148665788227015&w=2 The patches are available in a git branch: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git/log/?h=mmc-mq-v4.14-rc4 You can pull it to a clean kernel tree like this: git checkout -b mmc-test v4.14-rc4 git pull git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git mmc-mq-v4.14-rc4 I have now worked on it for more than a year. I was side tracked to clean up some code, move request allocation to be handled by the block layer, delete bounce buffer handling and refactoring the RPMB support. With the changes to request allocation, the patch set is a better fit and has shrunk from 16 to 12 patches as a result. It is still quite invasive. Yet it is something I think would be nice to merge for v4.16... The rationale for this approach was Arnd's suggestion to try to switch the MMC/SD stack around so as to complete requests as quickly as possible when they return from the device driver so that new requests can be issued. We are doing this now: the polling loop that was pulling NULL out of the request queue and driving the pipeline with a loop is gone with the next-to last patch ("block: issue requests in massive parallel"). This sets the stage for MQ to go in and hammer requests on the asynchronous issuing layer. We use the trick to set the queue depth to 2 to get two parallel requests pushed down to the host. I tried to set this to 4, the code survives it, the queue just have three items waiting to be submitted all the time. In my opinion this is also a better fit for command queueuing. Handling command queueing needs to happen in the asynchronous submission codepath, so instead of waiting on a pending areq, we just stack up requests in the command queue. It sounds simple but I bet this drives a truck through Adrians patch series. Sorry. :( We are not issueing new requests from interrupt context: I still have to post a work on a workqueue for it. Since there is the retune and background operations that need to be checked after every command and yeah, it needs to happen in blocking context as far as I know. I might make a hack trying to strip out the retune (etc) and instead run request until something fail and report requests back to the block layer in interrupt context. It would be an interesting experiment, but for later. We have parallelism in pre/post hooks also with multiqueue. All asynchronous optimization that was there for the old block layer is now also there for multiqueue. Last time I followed up with some open questions https://marc.info/?l=linux-mmc&m=149075698610224&w=2 I think these are now resolved. As a result, the last patch is no longer in RFC state. I think this works. (Famous last words, OK there WILL be regressions but hey, we need to do this.) You can see there are three steps: - I do some necessary refactoring and need to move postprocessing to after the requests have been completed. This clearly, as you can see, introduce a performance regression in the dd test with the patch: "mmc: core: move the asynchronous post-processing" It seems the random seek with find isn't much affected. - I continue the refactoring and get to the point of issueing requests immediately after every successful transfer, and the dd performance is restored with patch "mmc: queue: issue requests in massive parallel" - Then I add multiqueue on top of the cake. So before the change we have the nice performance we want so we can study the effect of just introducing multiqueueing in the last patch "mmc: switch MMC/SD to use blk-mq multiqueueing v4" PERFORMANCE BEFORE AND AFTER: BEFORE this patch series, on Ulf's next branch ending with commit cf653c788a29fa70e07b86492a7599c471c705de (mmc-next) Merge: 4dda8e1f70f8 eb701ce16a45 ("Merge branch 'fixes' into next") sync echo 3 > /proc/sys/vm/drop_caches sync time dd if=/dev/mmcblk3 of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.0GB) copied, 23.966583 seconds, 42.7MB/s real 0m 23.97s user 0m 0.01s sys 0m 3.74s mount /dev/mmcblk3p1 /mnt/ cd /mnt/ sync echo 3 > /proc/sys/vm/drop_caches sync time find . > /dev/null real 0m 3.24s user 0m 0.22s sys 0m 1.23s sync echo 3 > /proc/sys/vm/drop_caches sync iozone -az -i0 -i1 -i2 -s 20m -I -f /mnt/foo.test random random kB reclen write rewrite read reread read write 20480 4 1598 1559 6782 6740 6751 536 20480 8 2134 2281 11449 11449 11407 1145 20480 16 3695 4171 17676 17677 17638 1234 20480 32 5751 7475 23622 23622 23584 3004 20480 64 6778 8648 27937 27950 27914 3445 20480 128 6073 8115 29091 29080 29070 4892 20480 256 7106 7208 29658 29670 29657 6743 20480 512 8828 9953 29911 29905 29901 7424 20480 1024 6566 7199 27233 27236 27209 6808 20480 2048 7370 7403 27492 27490 27475 7428 20480 4096 7352 7456 28124 28123 28109 7411 20480 8192 7271 7462 28371 28369 28359 7458 20480 16384 7097 7478 28540 28538 28528 7464 AFTER this patch series ending with "mmc: switch MMC/SD to use blk-mq multiqueueing v4": sync echo 3 > /proc/sys/vm/drop_caches sync time dd if=/dev/mmcblk3 of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.0GB) copied, 24.358276 seconds, 42.0MB/s real 0m 24.36s user 0m 0.00s sys 0m 3.92s mount /dev/mmcblk3p1 /mnt/ cd /mnt/ sync echo 3 > /proc/sys/vm/drop_caches sync time find . > /dev/null real 0m 3.92s user 0m 0.26s sys 0m 1.21s sync echo 3 > /proc/sys/vm/drop_caches sync iozone -az -i0 -i1 -i2 -s 20m -I -f /mnt/foo.test random random kB reclen write rewrite read reread read write 20480 4 1614 1569 6913 6889 6876 531 20480 8 2147 2301 11628 11625 11581 1165 20480 16 3820 4256 17760 17764 17725 1549 20480 32 5814 7508 23148 23145 23123 3561 20480 64 7396 8161 27513 27527 27500 4177 20480 128 6707 9025 29160 29166 29139 5199 20480 256 7902 7860 29459 29456 29462 7307 20480 512 8061 11343 29888 29891 29881 6800 20480 1024 7076 7442 27702 27704 27700 7445 20480 2048 6846 8194 27417 27419 27418 6781 20480 4096 8115 6810 28113 28113 28109 8191 20480 8192 7254 7434 28413 28419 28414 7476 20480 16384 7090 7481 28623 28619 28625 7454 As you can see, performance is not affected, errors are in the noise margin. Linus Walleij (12): mmc: core: move the asynchronous post-processing mmc: core: add a workqueue for completing requests mmc: core: replace waitqueue with worker mmc: core: do away with is_done_rcv mmc: core: do away with is_new_req mmc: core: kill off the context info mmc: queue: simplify queue logic mmc: block: shuffle retry and error handling mmc: queue: stop flushing the pipeline with NULL mmc: queue/block: pass around struct mmc_queue_req*s mmc: block: issue requests in massive parallel mmc: switch MMC/SD to use blk-mq multiqueueing v4 drivers/mmc/core/block.c | 539 ++++++++++++++++++++++---------------------- drivers/mmc/core/block.h | 5 +- drivers/mmc/core/bus.c | 1 - drivers/mmc/core/core.c | 194 +++++++++------- drivers/mmc/core/core.h | 11 +- drivers/mmc/core/host.c | 1 - drivers/mmc/core/mmc_test.c | 31 +-- drivers/mmc/core/queue.c | 238 ++++++++----------- drivers/mmc/core/queue.h | 16 +- include/linux/mmc/core.h | 3 +- include/linux/mmc/host.h | 27 +-- 11 files changed, 503 insertions(+), 563 deletions(-) -- 2.13.6 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html