From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753969AbbCYRAc (ORCPT ); Wed, 25 Mar 2015 13:00:32 -0400 Received: from mail-wi0-f180.google.com ([209.85.212.180]:37266 "EHLO mail-wi0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752857AbbCYRA2 (ORCPT ); Wed, 25 Mar 2015 13:00:28 -0400 MIME-Version: 1.0 In-Reply-To: <20150325164428.GA1099@lst.de> References: <1427299449-26722-1-git-send-email-hch@lst.de> <20150325164428.GA1099@lst.de> Date: Wed, 25 Mar 2015 10:00:26 -0700 Message-ID: Subject: Re: [Linux-nvdimm] another pmem variant From: Dan Williams To: Christoph Hellwig Cc: linux-nvdimm , linux-fsdevel , "linux-kernel@vger.kernel.org" , X86 ML , Jens Axboe Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@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.