From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752306AbbCZQ5x (ORCPT ); Thu, 26 Mar 2015 12:57:53 -0400 Received: from mail-wg0-f54.google.com ([74.125.82.54]:32914 "EHLO mail-wg0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751701AbbCZQ5u (ORCPT ); Thu, 26 Mar 2015 12:57:50 -0400 Message-ID: <55143A8B.2060304@plexistor.com> Date: Thu, 26 Mar 2015 18:57:47 +0200 From: Boaz Harrosh User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Christoph Hellwig , linux-nvdimm@ml01.01.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org CC: ross.zwisler@linux.intel.com, axboe@kernel.dk, boaz@plexistor.com Subject: Re: another pmem variant V2 References: <1427358764-6126-1-git-send-email-hch@lst.de> In-Reply-To: <1427358764-6126-1-git-send-email-hch@lst.de> 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 03/26/2015 10:32 AM, Christoph Hellwig wrote: > Here is another version of the same trivial pmem driver, because two > obviously aren't enough. The first patch is the same pmem driver > that Ross posted a short time ago, just modified to use platform_devices > to find the persistant memory region instead of hardconding it in the > Kconfig. This allows to keep pmem.c separate from any discovery mechanism, > but still allow auto-discovery. > Hi Christoph So I've been trying to test your version, and play around with it. I currently have some problems, but this is the end of the week for me so I will debug and fix it after the weekend on Sunday. But just a heads up for what I stumbled on. For one this auto discovery of yours is very (very) nice but is a bit inconvenience. Before I would reserve a big chuck on each NUMA range on Kernel's memmap= And then at pmem map= would slice and dice it as I want hot style on modprobe with no need for reboot. Now I need to do it on reboot theoretically. (You know xfstest needs lots of devices some big some small ;-)) theoretically because if I try: memmap=1G!4G,1G!6G It will not boot at all. (will debug on Sunday) I must have 2 devices because each one is on another NUMA node. If I do memmap=2G!4G,1G!6G , which is a contiguous range it will give me only one device. Just an inconvenience. (And also this one sometimes does not boot) {All this in a VM for now did not even get to real HW yet} Also with the modprob pmem map= I was supporting a PCIE memory card but I guess I need to throw this one out the door. Am also posting an RFC cleanup to your pmem driver. RFC because I was not yet able to boot the all thing in our lab for heavy testing. Thanks Boaz > The other two patches are a heavily rewritten version of the code that > Intel gave to various storage vendors to discover the type 12 (and earlier > type 6) nvdimms, which I massaged into a form that is hopefully suitable > for mainline. > > Note that pmem.c really is the minimal version as I think we need something > included ASAP. We'll eventually need to be able to do other I/O from and > to it, and as most people know everyone has their own preferre method to > do it, which I'd like to discuss once we have the basic driver in. > > This has been tested both with a real NVDIMM on a system with a type 12 > capable bios, as well as with "fake persistent" memory using the memmap= > option. > > Changes since V1: > - s/E820_PROTECTED_KERN/E820_PMEM/g > - map the persistent memory as uncached > - better kernel parameter description > - various typo fixes > - MODULE_LICENSE fix > > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >