From patchwork Wed May 10 08:24:13 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 98969 Delivered-To: patch@linaro.org Received: by 10.140.96.100 with SMTP id j91csp105576qge; Wed, 10 May 2017 01:25:08 -0700 (PDT) X-Received: by 10.84.214.144 with SMTP id j16mr6358203pli.133.1494404708474; Wed, 10 May 2017 01:25:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1494404708; cv=none; d=google.com; s=arc-20160816; b=jZG4nXek25QFWCLiLy2YywfoR1ahj01Nx+tWqz0Ujwxa0DKarG9JVUcQ/Tg+tUVOLP +683V8hsiwZn7U16G7kcFHVrNXS3muLFmFB5HjeE9Tgj9L7lmb+PRHDl8+mX5EiRuMKd HLnnbf1YSQAm1oZ6S4Zwsshe2JloE4M9GgODs/xXCetcZ3mBFuS3+UkwDQ8ilLmgwYHZ vpIPWrJ72KdgRLLsnBvU0s+hMuR2QC2pqySlwKBcJ/oOtCr09TmdfYEzn6k1sCyGg+4m LFtFnc28iZ4aTynmqnQcldqzTMWSaJxaF2qyLVzDqODKKfTtpngLQhfKv4eHQa0zRSkz uecg== 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=J4GGZkC2PZyemSGsHrjkG2K2gJuKYYwSYrbCF7PQzSo=; b=b0U5krV2QsvzbJYbOiMR0Bt9pztH2VxbvL2YmTPCmmto6Gv2c6GYo3o/rCgh6xLCWM 9/ia3+URpM7IqgPcdRan9yv/VX05O60/20c4LPoiZnoSpqzSU3IUb1S4ClO09TL0qS4l IamoVd6Rq+HGrz8l+MdhXVIYzQjrY+xozFuujsDu5P3QGbDupujJpx94VQMkt6VH2D9I 6gGKEcyQtffo/ikK+hzJ3K0AIwSZzklR9lRAsNUPa8bD5QUHQgIAooKTNjZHFMKWFc9/ 7EnjxJCi1F/Y+KCwFzXyFjwRvGdNiWgOotQDm/h6SQAF6BjhBFZsb2ChThHVQtxtj9On GSHw== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; 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 f132si2315878pgc.250.2017.05.10.01.25.08; Wed, 10 May 2017 01:25:08 -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; 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 S1752272AbdEJIZD (ORCPT + 6 others); Wed, 10 May 2017 04:25:03 -0400 Received: from mail-wr0-f170.google.com ([209.85.128.170]:36852 "EHLO mail-wr0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752550AbdEJIYm (ORCPT ); Wed, 10 May 2017 04:24:42 -0400 Received: by mail-wr0-f170.google.com with SMTP id l50so32793309wrc.3 for ; Wed, 10 May 2017 01:24:41 -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=xWX0vYsY/taM9VF/K6YZZOWb4Ok8gG7Ok0SzNUDGMOs=; b=Oz5hf+r7bJ2FpfYEQCInONQZQ0yQKB1bfitCTU33DmzGTDBG4XMIBpuPDpwIAOWHWI dpaV0wj6BJvjl9AJ1pVRfwBn4kzfeGD1bzi6Ed5aSgI7An4mqm9sjSbAlFogTGrnC29o EVKCVqMmcfRGfwXFX5OLdIVsLVMfneB10dAFw= 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=xWX0vYsY/taM9VF/K6YZZOWb4Ok8gG7Ok0SzNUDGMOs=; b=OZEu+KUgEOmEHV9WR9AFGVTYtrmOoubvPnwh75vKUmi+nZjxvVKiq3sY8ln9AhLWNB N72RSmH3PDCDB6bi+cX+gjJlTiQAsmCEluaHuww/COR0GuUiJaB/yy2Int2jdBs/qov0 ZNr34jYBXPtAP1/+93BVe+C+1fRX4vH+QvjcaPNKWqZCQ3zw2OlWgPsAJYa8uMxCy70N /SSd8kyfJo1lkDnHy+oinrO0MjKSVHi8pnEp5Itvz+DRthkdydb+ewUinjAGde5jjNNG bmUtMUMl6dhIlsUQ0EW1vNmDOTnt0heYd8eHKuztult6nmpjFxvJ6DF55Re+1IIltOD1 VH/Q== X-Gm-Message-State: AODbwcD58OS1jjfSyfBkvxLACzSkIlYmV7WmQEo5wWBe4YxkP0RIjtSX yZzSpyde/X37A0az X-Received: by 10.25.211.70 with SMTP id k67mr2292276lfg.87.1494404680719; Wed, 10 May 2017 01:24:40 -0700 (PDT) Received: from genomnajs.ideon.se ([85.235.10.227]) by smtp.gmail.com with ESMTPSA id 17sm401500ljo.56.2017.05.10.01.24.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 May 2017 01:24:39 -0700 (PDT) From: Linus Walleij To: linux-mmc@vger.kernel.org, Ulf Hansson , Adrian Hunter Cc: linux-block@vger.kernel.org, Jens Axboe , Christoph Hellwig , Arnd Bergmann , Bartlomiej Zolnierkiewicz , Paolo Valente , Linus Walleij Subject: [PATCH 0/5] mmc: core: modernize ioctl() requests Date: Wed, 10 May 2017 10:24:13 +0200 Message-Id: <20170510082418.10513-1-linus.walleij@linaro.org> X-Mailer: git-send-email 2.9.3 Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org This is a series that starts to untangle the MMC "big host lock", i.e. what is taken by issueing mmc_claim_host() which usually happens through mmc_get_card(). The host lock is standing in the way of a bunch of modernizations, because the block layer interface takes this lock when a new request arrives, then will not release it until the queue is empty, which is detected by getting NULL from blk_fetch_request(). This does not work with the new MQ block layer because it issues requests asynchrously and there is no way of telling if the submit queue is empty or not. Block requests must always be served. Trying to introduce an interface for figuring out if the queue is empty is probably generally a bad idea as it will require cross-talk between all CPUs and then we hit Amdahl's Law again when scaling upwards with CPUs. So Arnd Bergmann suggested that whatever parallel requests the host lock is protecting, maybe these requests can be funneled through the block layer itself? It turns out that most block drivers already do this, by using the "special" block requests REQ_OP_DRV_IN and REQ_OP_DRV_OUT. And it is what we should have done from the beginning. To do this, the per-request extra data (which I think is also referred to as "tag") need to be handled the same way that all other block drivers do it: allocate it through the block layer. In the MMC stack, this extra per-request data (tag) is called struct mmc_queue_req. So the second patch convert to using the generic block layer mechanism to allocate tags. This makes the core simpler IMO and that is why the patch series has negative line count. We move stuff over to the block layer. The first patch cleans out bounce buffer configurability and move that to be a property of the host rather than a Kconfig option in order to make it cleaner to do the rest of the refactorings. The last two patches moves the ioctl() calls over to use the new per-request tags and removes two instances of mmc_get_card(), so we start to untangle the big host lock. This approach can be used to get rid of the debugfs mmc_get_card() as well but I want to start with the ioctl()s. It already fixes a problem: userspace and the block layer could essentially starve each other by bombing requests from either block access or ioctl() congesting the host lock. With this, ioctl() operations get scheduled by the block layer with everything else. Not that I know how the block layer prioritizes REQ_OP_DRV_IN and REQ_OP_DRV_OUT requests, but I am confident it does a better job than the first-come-first-served host lock. This drives a truck through mine and Adrians patch sets for multiqueue and command queueing respectively, but I think that both of our patch series will get easier to implement if we exploit these patches as a base for future work, so if they can get positive reviews and does not make everything explode, I would suggest we merge them as a starter for the v4.13 kernel cycle. Linus Walleij (5): mmc: core: Delete bounce buffer Kconfig option mmc: core: Allocate per-request data using the block layer core mmc: block: Tag is_rpmb as bool mmc: block: move single ioctl() commands to block requests mmc: block: move multi-ioctl() to use block layer drivers/mmc/core/Kconfig | 18 ---- drivers/mmc/core/block.c | 126 +++++++++++++++---------- drivers/mmc/core/queue.c | 235 ++++++++++++---------------------------------- drivers/mmc/core/queue.h | 26 +++-- drivers/mmc/host/cavium.c | 3 + drivers/mmc/host/pxamci.c | 6 ++ include/linux/mmc/card.h | 2 - include/linux/mmc/host.h | 1 + 8 files changed, 161 insertions(+), 256 deletions(-) -- 2.9.3 -- 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