From patchwork Mon May 4 16:43:01 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ross Zwisler X-Patchwork-Id: 6328111 Return-Path: X-Original-To: patchwork-linux-nvdimm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id F1F79BEEE1 for ; Mon, 4 May 2015 16:43:07 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 025212034A for ; Mon, 4 May 2015 16:43:07 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 07B9620351 for ; Mon, 4 May 2015 16:43:05 +0000 (UTC) Received: from ml01.vlan14.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id CD3071825B7; Mon, 4 May 2015 09:43:04 -0700 (PDT) X-Original-To: linux-nvdimm@ml01.01.org Delivered-To: linux-nvdimm@ml01.01.org Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ml01.01.org (Postfix) with ESMTP id 8E8ED1825B3 for ; Mon, 4 May 2015 09:43:03 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 04 May 2015 09:43:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,366,1427785200"; d="scan'208";a="689693368" Received: from theros.lm.intel.com (HELO [10.232.112.154]) ([10.232.112.154]) by orsmga001.jf.intel.com with ESMTP; 04 May 2015 09:43:03 -0700 Message-ID: <1430757781.5434.6.camel@theros.lm.intel.com> From: Ross Zwisler To: Christoph Hellwig Date: Mon, 04 May 2015 10:43:01 -0600 In-Reply-To: <20150326080656.GE26540@lst.de> References: <1427299449-26722-1-git-send-email-hch@lst.de> <1427299449-26722-2-git-send-email-hch@lst.de> <1427314913.14654.1.camel@theros.lm.intel.com> <20150326080656.GE26540@lst.de> X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20.rez) Mime-Version: 1.0 Cc: axboe@kernel.dk, linux-nvdimm@ml01.01.org, x86@kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [Linux-nvdimm] [PATCH 1/3] pmem: Initial version of persistent memory driver X-BeenThere: linux-nvdimm@lists.01.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Linux-nvdimm developer list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Thu, 2015-03-26 at 09:06 +0100, Christoph Hellwig wrote: > On Wed, Mar 25, 2015 at 02:21:53PM -0600, Ross Zwisler wrote: > > What needed to be fixed with the partition support? I used to have real > > numbers for first_minor and passed into alloc_disk(), but simplified it based > > on code found in this commit in the nvme driver: > > > > 469071a37afc NVMe: Dynamically allocate partition numbers > > > > This has worked fine for me - is there some test case in which it breaks? > > Yes, if CONFIG_DEBUG_BLOCK_EXT_DEVT isn't set that code doesn't work at all. I can't figure out a use case that breaks when using dynamically allocated minors without CONFIG_DEBUG_BLOCK_EXT_DEVT. The patch that I've been testing against is at the bottom of this mail. Here are the minors that I get when creating a bunch of partitions using the current code with PMEM_MINORS=16, with CONFIG_DEBUG_BLOCK_EXT_DEVT turned off: pmem0 249:0 0 63.5G 0 rom ??pmem0p1 249:1 0 1G 0 part ??pmem0p2 249:2 0 1G 0 part ??pmem0p3 249:3 0 1G 0 part ??pmem0p4 249:4 0 1G 0 part ??pmem0p5 249:5 0 1G 0 part ??pmem0p6 249:6 0 1G 0 part ??pmem0p7 249:7 0 1G 0 part ??pmem0p8 249:8 0 1G 0 part ??pmem0p9 249:9 0 1G 0 part ??pmem0p10 249:10 0 1G 0 part ??pmem0p11 249:11 0 1G 0 part ??pmem0p12 249:12 0 1G 0 part ??pmem0p13 249:13 0 1G 0 part ??pmem0p14 249:14 0 1G 0 part ??pmem0p15 249:15 0 1G 0 part ??pmem0p16 259:0 0 1G 0 part ??pmem0p17 259:1 0 1G 0 part ??pmem0p18 259:2 0 1G 0 part With dynamic minor allocation, with CONFIG_DEBUG_BLOCK_EXT_DEVT turned off: pmem0 259:0 0 63.5G 0 rom ??pmem0p1 259:1 0 1G 0 part ??pmem0p2 259:2 0 1G 0 part ??pmem0p3 259:3 0 1G 0 part ??pmem0p4 259:4 0 1G 0 part ??pmem0p5 259:5 0 1G 0 part ??pmem0p6 259:6 0 1G 0 part ??pmem0p7 259:7 0 1G 0 part ??pmem0p8 259:8 0 1G 0 part ??pmem0p9 259:9 0 1G 0 part ??pmem0p10 259:10 0 1G 0 part ??pmem0p11 259:11 0 1G 0 part ??pmem0p12 259:12 0 1G 0 part ??pmem0p13 259:13 0 1G 0 part ??pmem0p14 259:14 0 1G 0 part ??pmem0p15 259:15 0 1G 0 part ??pmem0p16 259:16 0 1G 0 part ??pmem0p17 259:17 0 1G 0 part ??pmem0p18 259:18 0 1G 0 part And with CONFIG_DEBUG_BLOCK_EXT_DEVT turned on: pmem0 259:262144 0 63.5G 0 rom ??pmem0p1 259:786432 0 1G 0 part ??pmem0p2 259:131072 0 1G 0 part ??pmem0p3 259:655360 0 1G 0 part ??pmem0p4 259:393216 0 1G 0 part ??pmem0p5 259:917504 0 1G 0 part ??pmem0p6 259:65536 0 1G 0 part ??pmem0p7 259:589824 0 1G 0 part ??pmem0p8 259:327680 0 1G 0 part ??pmem0p9 259:851968 0 1G 0 part ??pmem0p10 259:196608 0 1G 0 part ??pmem0p11 259:720896 0 1G 0 part ??pmem0p12 259:458752 0 1G 0 part ??pmem0p13 259:983040 0 1G 0 part ??pmem0p14 259:32768 0 1G 0 part ??pmem0p15 259:557056 0 1G 0 part ??pmem0p16 259:294912 0 1G 0 part ??pmem0p17 259:819200 0 1G 0 part ??pmem0p18 259:163840 0 1G 0 part With CONFIG_DEBUG_BLOCK_EXT_DEVT the minors are all mangled due to blk_mangle_minor(), but I think that all three configs work? Was there maybe confusion between that config option and the GENHD_FL_EXT_DEVT gendisk flag, which AFAIK are independent? Is there a use case that breaks when using dynamic minors without CONFIG_DEBUG_BLOCK_EXT_DEVT? Thanks, - Ross --- >8 --- From 6202dc7c1ef765faebb905161860c6b9ab19cc8a Mon Sep 17 00:00:00 2001 From: Ross Zwisler Date: Mon, 4 May 2015 10:26:54 -0600 Subject: [PATCH] pmem: Dynamically allocate partition numbers Dynamically allocate minor numbers for partitions instead of statically preallocating them. Inspired by this commit: 469071a37afc NVMe: Dynamically allocate partition numbers Signed-off-by: Ross Zwisler --- drivers/block/nd/pmem.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/block/nd/pmem.c b/drivers/block/nd/pmem.c index 900dad61a6b9..b977def8981e 100644 --- a/drivers/block/nd/pmem.c +++ b/drivers/block/nd/pmem.c @@ -26,8 +26,6 @@ #include #include "nd.h" -#define PMEM_MINORS 16 - struct pmem_device { struct request_queue *pmem_queue; struct gendisk *pmem_disk; @@ -185,12 +183,12 @@ static struct pmem_device *pmem_alloc(struct device *dev, struct resource *res) blk_queue_max_hw_sectors(pmem->pmem_queue, 1024); blk_queue_bounce_limit(pmem->pmem_queue, BLK_BOUNCE_ANY); - disk = alloc_disk(PMEM_MINORS); + disk = alloc_disk(0); if (!disk) goto out_free_queue; disk->major = pmem_major; - disk->first_minor = PMEM_MINORS * pmem->id; + disk->first_minor = 0; disk->fops = &pmem_fops; disk->private_data = pmem; disk->queue = pmem->pmem_queue;