From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Williams Subject: Re: [Linux-nvdimm] another pmem variant Date: Wed, 25 Mar 2015 10:00:26 -0700 Message-ID: References: <1427299449-26722-1-git-send-email-hch@lst.de> <20150325164428.GA1099@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: linux-nvdimm , linux-fsdevel , "linux-kernel@vger.kernel.org" , X86 ML , Jens Axboe To: Christoph Hellwig Return-path: In-Reply-To: <20150325164428.GA1099@lst.de> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Mar 25, 2015 at 9:44 AM, Christoph Hellwig wrote: > On Wed, Mar 25, 2015 at 09:33:52AM -0700, Dan Williams wrote: >> This is mostly ok and does not collide too much with the upcoming ACPI >> mechanism for this stuff. I do worry that the new >> "memmap=nn[KMG]!ss[KMG]" kernel command line option will only be >> relevant for at most one kernel cycle given the imminent publication >> of the spec that unblocks our release. > > I don't think we can just get rid of it as legacy systems won't be > upgraded to the new discovery mechanism. Or do you mean you plan to > introduce a better override on the command line? In that case speak > up now! The kernel command line would simply be the standard/existing memmap= to reserve a memory range. Then, when the platform device loads, it does a request_firmware() to inject a binary table that further carves memory into ranges to which the pmem driver attaches. No need for the legacy system BIOS to be upgraded to the "new way". >> Our planned solution to the "legacy pmem" problem is to have a >> userspace utility craft a list of address ranges in the form that ACPI >> expects and attach that to a platform device (one time setup). It >> only requires that the memory be marked reserved, not necessarily >> marked type-12. > > I can't see any benefit of that over just doign the right thing in > kernel space. It does do the right thing in kernel space. The userspace utility creates the binary table (once) that can be compiled into the platform device driver or auto-loaded by an initrd. The problem with a new memmap= is that it is too coarse. For example you can't do things like specify a pmem range per-NUMA node.