From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753581AbcAVO4G (ORCPT ); Fri, 22 Jan 2016 09:56:06 -0500 Received: from mga03.intel.com ([134.134.136.65]:10326 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753166AbcAVO4B (ORCPT ); Fri, 22 Jan 2016 09:56:01 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,331,1449561600"; d="scan'208";a="887013050" Date: Fri, 22 Jan 2016 14:56:00 +0000 From: Keith Busch To: Linus Torvalds Cc: Jens Axboe , Stefan Haberland , Linux Kernel Mailing List , linux-s390 , Sebastian Ott Subject: Re: [BUG] Regression introduced with "block: split bios to max possible length" Message-ID: <20160122145559.GA21984@localhost.localdomain> References: <56A0F1CA.4010303@linux.vnet.ibm.com> <56A14EE4.1020008@fb.com> <20160121225127.GA30993@localhost.localdomain> <20160122032135.GA9244@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 21, 2016 at 08:15:37PM -0800, Linus Torvalds wrote: > For the case of nvme, for example, I think the max sector number is so > high that you'll never hit that anyway, and you'll only ever hit the > chunk limit. No? The device's max transfer and chunk size are not very large, both fixed at 128KB. We can lose ~70% of potential throughput when IO isn't aligned, and end users reported this when the block layer stopped splitting on alignment for the NVMe drive. So it's a big deal for this h/w, but now I feel awkward defending a device specific feature for the generic block layer. Anyway, the patch was developed with incorrect assumptions. I'd still like to try again after reconciling the queue limit constraints, but I defer to Jens for the near term. Thanks!