From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752158AbbBVRFU (ORCPT ); Sun, 22 Feb 2015 12:05:20 -0500 Received: from mail-wi0-f177.google.com ([209.85.212.177]:42892 "EHLO mail-wi0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751969AbbBVRFR (ORCPT ); Sun, 22 Feb 2015 12:05:17 -0500 Message-ID: <54EA0C48.4020408@plexistor.com> Date: Sun, 22 Feb 2015 19:05:12 +0200 From: Boaz Harrosh User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Christoph Hellwig CC: Dan Williams , Matthew Wilcox , Ingo Molnar , Ross Zwisler , x86@kernel.org, linux-kernel , "Roger C. Pao" , Thomas Gleixner , Linus Torvalds , linux-nvdimm , "H. Peter Anvin" Subject: Re: [Linux-nvdimm] [PATCH 0/2] e820: Fix handling of NvDIMM chips References: <54E1CF5B.9020905@plexistor.com> <20150216220302.GF3364@wil.cx> <54E2FEF2.8060701@plexistor.com> <20150219004731.GA5477@infradead.org> <54E5AC11.8070608@plexistor.com> <20150222162708.GA4327@infradead.org> In-Reply-To: <20150222162708.GA4327@infradead.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/22/2015 06:27 PM, Christoph Hellwig wrote: > On Thu, Feb 19, 2015 at 11:25:37AM +0200, Boaz Harrosh wrote: >> I do not see why you need the nvdimm_type= kernel option at all. >> >> I have here a script that auto detects any NvDIMM. It works with all >> the chips that I have access to. And Also it has support for if you have >> memmap=sss\$aaa. >> For all these detected regions it will load a pmem device. >> >> It is easy to filter for any type of memory you want. What >> will the (annoying) kernel option give you? >> >> OK I might be jumping the guns, send the patch and I'll look >> at it. > > The kernel option means we can autodetect the nvdimms in kernel space > with just that option set, no need for needing userspace setup. > Do you mean that pmem is: - Loaded without any parameters. - A new API is defined for enumerating NvDIMMs. pmem uses that for creating new devices. - e820 registers such devices according to special type passed on Kernel command-line. (That could be a Kconfig as well you know, I hate Kernel command-line) (Similar to what very old prd.c did only not hacking the e820 lists directly) > How does your script / patch work? > Easy just parses /proc/iomem + looks at Kernel command line. It has support not only for type-12 memory but also for "reserved" regions, made by memmap=sss$aaa stated on command line. And/or also an /etc/pmem.cfg list of regions. So you can go automatic or manual or a mix of both (And slice a region for xfstests scratch device). In any case it helps to have my patches, but also old Kernels are supported with the BLK_DEV_PMEM_IGNORE_REQUEST_MEM_RET. On old Kernels they are all "reserved" regions, no unknown-12 type. Once a list of regions or split-regions is established pmem is loaded with that list. > I won't be back to my nvdimm enabled hardware until after LSF/MM, > so any work from me in this area will have to wait a bit. > Have a good time. Will you guys have a talk about pmem ? If yes I would love it if you guys can talk about the use-of-pages-with-pmem. Please tell me I can write a looong argument about it. Thanks Boaz