Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1034185AbcJ1RSU (ORCPT ); Fri, 28 Oct 2016 13:18:20 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:44978 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030424AbcJ1RSS (ORCPT ); Fri, 28 Oct 2016 13:18:18 -0400 Date: Fri, 28 Oct 2016 18:17:44 +0100 From: Mark Brown To: Arnd Bergmann Cc: Jens Axboe , Linus Walleij , Ulf Hansson , Paolo Valente , Christoph Hellwig , Bart Van Assche , Jan Kara , Tejun Heo , linux-block@vger.kernel.org, Linux-Kernal , Hannes Reinecke , Grant Likely , James Bottomley , Bartlomiej Zolnierkiewicz Message-ID: <20161028171744.n3l7brpcphi4duah@sirena.org.uk> References: <1477474082-2846-1-git-send-email-paolo.valente@linaro.org> <3d0b38bb-537d-94ff-574f-587bad949fdd@kernel.dk> <2423164.8ioLhGisxr@wuerfel> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cpog7nqtpk6cugy2" Content-Disposition: inline In-Reply-To: <2423164.8ioLhGisxr@wuerfel> X-Cookie: Serenity through viciousness. User-Agent: NeoMutt/20161014 (1.7.1) X-SA-Exim-Connect-IP: 64.88.227.140 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: No (on mezzanine.sirena.org.uk); Unknown failure Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1584 Lines: 41 --cpog7nqtpk6cugy2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Oct 28, 2016 at 06:05:35PM +0200, Arnd Bergmann wrote: > On Friday, October 28, 2016 9:30:07 AM CEST Jens Axboe wrote: > > Also, 4.8 and newer have support for BLK_MQ_F_BLOCKING, if you need to > > block in ->queue_rq(). That could eliminate the need to offload to a > > kthread manually. > I think the main reason for the kthread is that on ARM and other > architectures, the dma mapping operations are fairly slow (for > cache flushes or bounce buffering) and we want to minimize the > time between subsequent requests being handled by the hardware. > This is not unique to MMC in any way, MMC just happens to be > common on ARM and it is limited by its lack of hardware > command queuing. Plus the fact that MMC (and SD) have some *relatively* high performance implementations which amplify the effects of desaturating the hardware - the faster the hardware is the more noticable the overhead of stalling it becomes. --cpog7nqtpk6cugy2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAABCAAGBQJYE4g4AAoJECTWi3JdVIfQ3WAH+gLuYxkY5tlON/3vAdv/Fl0t L6Q7pgMANhF6B8HRStco7AQAqVvb5cFcD8QLV8Opi36eq9nadmI26R3JvktzLagH fdtq+Aqqs1ldjBSULOmn15PioF6n46lpz9v6TM0MY0WWj1kFARfzGrZ64jUMTCR1 BuGCFhutnmFRLK+SOjxh7YgdW7t30YV+wYtYb7XYy/una7GvdolOzCN3puWjWWDr IssJLzyfhMO8f7oO9n1W+mBHgOEPx0+ht62eZdGfSMNpQJwg2tAd5LNgaj4OwC0n REdjDS0nX1JSauhWOMzv7CLUmodVQ+Prsp9k8xZ8t3dR3TODgn/FxxdZzpRtp60= =lkfo -----END PGP SIGNATURE----- --cpog7nqtpk6cugy2--