From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031217AbbJ3WNd (ORCPT ); Fri, 30 Oct 2015 18:13:33 -0400 Received: from e18.ny.us.ibm.com ([129.33.205.208]:59049 "EHLO e18.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1031216AbbJ3WNb (ORCPT ); Fri, 30 Oct 2015 18:13:31 -0400 X-IBM-Helo: d01dlp02.pok.ibm.com X-IBM-MailFrom: nacc@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org;sparclinux@vger.kernel.org Date: Fri, 30 Oct 2015 15:13:24 -0700 From: Nishanth Aravamudan To: Keith Busch Cc: aik@ozlabs.ru, linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, Christoph Hellwig , paulus@samba.org, sparclinux@vger.kernel.org, willy@linux.intel.com, linuxppc-dev@lists.ozlabs.org, David Miller , david@gibson.dropbear.id.au Subject: Re: [PATCH 1/1 v3] drivers/nvme: default to 4k device page size Message-ID: <20151030221324.GM7716@linux.vnet.ibm.com> References: <20151026.182746.1323901353520152838.davem@davemloft.net> <20151027222010.GD7716@linux.vnet.ibm.com> <20151027223643.GA25332@localhost.localdomain> <20151027.175443.140992924519172506.davem@davemloft.net> <20151028135922.GA27909@localhost.localdomain> <20151029115536.GA28090@infradead.org> <20151029155701.GJ7716@linux.vnet.ibm.com> <20151029172043.GA8343@localhost.localdomain> <20151030213511.GK7716@linux.vnet.ibm.com> <20151030214848.GC13904@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151030214848.GC13904@localhost.localdomain> X-Operating-System: Linux 3.13.0-40-generic (x86_64) User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15103022-0045-0000-0000-0000021B06FD Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30.10.2015 [21:48:48 +0000], Keith Busch wrote: > On Fri, Oct 30, 2015 at 02:35:11PM -0700, Nishanth Aravamudan wrote: > > Given that it's 4K just about everywhere by default (and sort of > > implicitly expected to be, I guess), I think I'd prefer we default to > > 4K. That should mitigate the performance impact (I'll ask our IO team to > > do some runs, but since this impacts functionality on some hardware, I > > don't think it's too relevant for now). Unless there are NVMe devcies > > with a MPSMAX < 4K? > > Right, I assumed MPSMIN was always 4k for the same reason you mentioned, > but you can hard code it like you've done in your patch. > > The spec defines MPSMAX such that it's impossible to find a device > with MPSMAX < 4k. Great, thanks! -Nish