Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp4118692ybc; Tue, 26 Nov 2019 04:11:27 -0800 (PST) X-Google-Smtp-Source: APXvYqx+PrOiM3pcL+3CXC5Kb3uWQBXw7n9fumuKJo0nW1lu/T3O1/UFogNCKpkaKrTYvG2Oey6o X-Received: by 2002:aa7:cc0f:: with SMTP id q15mr24397910edt.71.1574770287586; Tue, 26 Nov 2019 04:11:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574770287; cv=none; d=google.com; s=arc-20160816; b=g3EX0PyAPklY9I6SYLPdJ+EUPxOhMXei2fI174Zok8QVcpvJUNlgnTFC/I7NvUpUfR BsiW7Zi31Hjn7YsnUTCuKv/JlIHCnL4LQ6oxJ7oUNOjq9qCFdB5aStcl4qc2K1tbo3ZG ABu6KIOiEv0FRhWZimkm1r7Ael7RugvLCl9zB5VrZBvwfDIt08LiYRMVKjtQD8vUiHuz ht22zEBZCjjg0CO4HBwqQ2/xs3Nu0RWewGW1b+w8AoSTNQqGn16cO8UwGhZE8qA9RAYG ihA558TLbehkU7OvbaaGIch0NxBZGELv+lAgpSVV2Pzs7T1q7I+jDVRYoxYu7Ul292wN Mueg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=0q+VexSmZ0wBBWsbuqVPPjLVGjl/g2HG1MXRz+mf0zg=; b=gur5ykDBcErsQj0IX8RTVsiPSpluuBZZ3OJ8Zi57WbAj3JmNzHfQIGHSbNFJ6Ow9Gu sd2pmZFTiedb/jTwuQpm4oJZ9MgkDJJ/PuCFtWpt5ocuklMvCUk5dItUV+0wwOqd58RE cw37fBVCkQCqR/BvJzXUmQ8UDtQLieNt7mqq4+ptki5o7vz75LWkXCjAPeYBeoRbi8lY ikNWlDfyjzISCAlXUpXmOqibEqL9Uw2b/UEFKZ9ac0I8tpUGL45LlStMLeDNCK8mRUUV XnoAKi8P9y5LfmwvQH2x1/hpoV7Wp3xas6AbAJM2tVaGkzLA1ZD+XYeASOtpPYd5xKCe WP3Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w54si8045898eda.214.2019.11.26.04.11.03; Tue, 26 Nov 2019 04:11:27 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727653AbfKZJyW (ORCPT + 99 others); Tue, 26 Nov 2019 04:54:22 -0500 Received: from mout.kundenserver.de ([212.227.17.24]:45003 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727397AbfKZJyW (ORCPT ); Tue, 26 Nov 2019 04:54:22 -0500 Received: from mail-qv1-f50.google.com ([209.85.219.50]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.145]) with ESMTPSA (Nemesis) id 1MIcux-1id3ni2ZFN-00Efhg; Tue, 26 Nov 2019 10:54:19 +0100 Received: by mail-qv1-f50.google.com with SMTP id t5so162603qvs.5; Tue, 26 Nov 2019 01:54:19 -0800 (PST) X-Gm-Message-State: APjAAAWytZ+TnxxhQykXakGeTpTnytGBlQEHkltdCYIT7uidqL9O9RpR LtoZpb7GL+XGAGyPC6EZrA8NeMHu9b6emaj5Gww= X-Received: by 2002:ad4:404e:: with SMTP id r14mr32738089qvp.4.1574762058335; Tue, 26 Nov 2019 01:54:18 -0800 (PST) MIME-Version: 1.0 References: <1C0831B6-CA26-4794-9686-E7384713C756@linaro.org> In-Reply-To: <1C0831B6-CA26-4794-9686-E7384713C756@linaro.org> From: Arnd Bergmann Date: Tue, 26 Nov 2019 10:54:01 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v6 0/4] Add MMC software queue support To: Paolo Valente Cc: "(Exiting) Baolin Wang" , Baolin Wang , Adrian Hunter , Ulf Hansson , Asutosh Das , Orson Zhai , Lyra Zhang , Linus Walleij , Vincent Guittot , linux-mmc , "linux-kernel@vger.kernel.org" , Hannes Reinecke , linux-block Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:F4qBgONcda6uvVnW/sY+/qgy/oA8tIrpZ0Ug69hENvuxR7e1QFZ GVtk3336XAPu6j44gZNVR0aZaQJoGuEZuSyqxEvXnT8FPsS1cNLw7wIGwaN2GxXImb4Abem Djva5NMFgIq4vAug39A6Ll0vwiqZll3nvDWp07/PZ6XSLtV81XvQev7D6LxiX72AjUZ735i 4dTqGIrwkF4scyU7Uk1/g== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:9juBk/clAeQ=:7lxmgSuGXYgYG4mFNRV5ky EgIhUJjBmo6Poe0zd7sQOSz2l86811OMt0m8yFWj7KRFGsb+VujbbnSar2cKGmIjxmS+DytkR 76dOD4BPiks6uthQ6HYMwChaX4TAeXmy+cLcObZnSfwTjRHkbfJvxUuew87SJE2VylnVFk5nj jpJ5K4AZbjaimY75DynryB7ii95yVWLSQqrynPF/oK199NqNNanhUCfFI6sFLakboRbGOVNva XMUj/musrBWWwuxomKYcv2ckpIQlKkpUZDxKb4PV/VmlPAsb6HzPLzgshxHxxxPwj+0qFayDU ndsNHh1QAWDuGdMjZVrjXC6o9xK3aR/ZfHG2PI6BICWBBVxut/86PbWnAWvvH96pO3soj+eU2 6dnFMWrVZasYSUZaJTRljU8uIdtULTYpjQSwFxtsLLliJMtR1WDaxSy+U0zLdA4z3fXeTChAf Qfg4jJZbuBa+gaGOtZD/emGzYQBuvMJWxaa4qMl2l8PEFE+fimeF353Ah39QZ/5P+fXjnvAuk zh4k17/dD3kq9muONF2BnovnjZR6KcM3VXOpzqXnqReHSKi+EAVJfWFj5D6V/gfi4Xku10GDu K8u+Rp83WUgDnAizXOZSLb/MMSrPyYVqNQ3aIJxrg0kDrFJR+XcJ+QS+9OOReGlntRua799iw s1IwVejyxC5PTw0y0isACEIDmz0xcvCVTBDuwPNMMVn7BwJ8bJUJoTnVZrnMXDVBMvN8gt15W JbraY1uRYr5Ty7Mpk1vlYZ5znBWdx3+pH4bdkvUoLnTkD5Sd7EskT0wSWxDJt7uax8ykeKyIT esA+l870E6mQBPG1XinvPGF+AY+yP8MtLbBzeKmpS21ur5vazgZyv1+naqfDKKM5fa5jzdYb8 3FP76n/dLJqIRxyyqhxg== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 26, 2019 at 8:41 AM Paolo Valente wrote: > > Il giorno 22 nov 2019, alle ore 10:50, Arnd Bergmann ha scritto: > > On Mon, Nov 18, 2019 at 11:04 AM (Exiting) Baolin Wang wrote: > > Paolo, can you comment on why this is currently done, or if it can > > be changed? It seems to me that sending multiple requests at > > once would also have a significant benefit on the per-request overhead > > on NVMe devices with with bfq. > > > > Hi, > actually, "one request dispatched at a time" is not a peculiarity of > bfq. Any scheduler can provide only one request at a time, with the > current blk-mq API for I/O schedulers. > > Yet, when it is time to refill an hardware queue, blk-mq pulls as many > requests as it deems appropriate from the scheduler, by invoking the > latter multiple times. See blk_mq_do_dispatch_sched() in > block/blk-mq-sched.c. > > I don't know where the glitch for MMC is with respect to this scheme. Right, this is what is puzzling me as well: in both blk_mq_do_dispatch_sched() and blk_mq_do_dispatch_ctx(), we seem to always take one request from the scheduler and dispatch it to the device, regardless of the driver or the scheduler, so there should only ever be one request in the local list. Yet, both the blk_mq_dispatch_rq_list() function and the NVMe driver appear to be written based on the idea that there are multiple entries in this list. The one place that I see putting multiple requests on the local list before dispatching them is the end of blk_mq_sched_dispatch_requests(): if (!list_empty(&rq_list)) { ... } } else if (has_sched_dispatch) { blk_mq_do_dispatch_sched(hctx); } else if (hctx->dispatch_busy) { /* dequeue request one by one from sw queue if queue is busy */ blk_mq_do_dispatch_ctx(hctx); } else { -> blk_mq_flush_busy_ctxs(hctx, &rq_list); <---- blk_mq_dispatch_rq_list(q, &rq_list, false); } So as you said, if we use an elevator (has_sched_dispatch == true), we only get one request, but without an elevator, we get into this optimized path. Could we perhaps change the ops.dispatch_request() function to pass down the list as in https://paste.ubuntu.com/p/MfSRwKqFCs/ ? Arnd