Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751963AbbEDQoH (ORCPT ); Mon, 4 May 2015 12:44:07 -0400 Received: from mga03.intel.com ([134.134.136.65]:19207 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751168AbbEDQnE (ORCPT ); Mon, 4 May 2015 12:43:04 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,366,1427785200"; d="scan'208";a="689693368" Message-ID: <1430757781.5434.6.camel@theros.lm.intel.com> Subject: Re: [PATCH 1/3] pmem: Initial version of persistent memory driver From: Ross Zwisler To: Christoph Hellwig Cc: linux-nvdimm@ml01.01.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, boaz@plexistor.com, axboe@kernel.dk 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> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20.rez) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5456 Lines: 154 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; -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/