From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754635AbbCaQI4 (ORCPT ); Tue, 31 Mar 2015 12:08:56 -0400 Received: from verein.lst.de ([213.95.11.211]:55941 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754183AbbCaQIz (ORCPT ); Tue, 31 Mar 2015 12:08:55 -0400 Date: Tue, 31 Mar 2015 18:08:53 +0200 From: Christoph Hellwig To: Boaz Harrosh Cc: Christoph Hellwig , linux-nvdimm@ml01.01.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, ross.zwisler@linux.intel.com, axboe@kernel.dk Subject: Re: another pmem variant V2 Message-ID: <20150331160853.GA1152@lst.de> References: <1427358764-6126-1-git-send-email-hch@lst.de> <55143A8B.2060304@plexistor.com> <20150331092526.GA25958@lst.de> <551A762A.7090307@plexistor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <551A762A.7090307@plexistor.com> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 31, 2015 at 01:25:46PM +0300, Boaz Harrosh wrote: > The problem I see is that if I state a memmap=nn!aa that crosses a NUMA > boundary then the machine will not boot. > So BTW for sure I need that "don't merge E820_PMEM ranges" patch because > otherwise I will not be able to boot if I have pmem on both NUMA nodes > and they happen to be contiguous. Ok. > Regarding the SQUASHMEs to PMEM. Originally I had them as 3-4 patches. > But I thought since you are squashing them into a single submitted patch > I can just send just the one patch. Tell me what you prefer and I'll > resend (The one vs the three) The slpit is mostly to get a good description for each change. > And one last issue. I have some configuration "hardness" with the > memmap=nn!aa Kernel command line API, it was better for me with the > pmem map= module param. Will you be OK if I split pmem_probe() into > calling pmem_alloc(addr, length), so I can keep an out-of-tree patch > that adds the map= parameter to pmem? Can't your out of tree patch do that as well? In fact you might want to rewrite it to a module that allows your to create/destroy the platform_devices you use. And for your PCIe case I'd really prefer a proper in-tree PCI driver for it.