Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753301AbbHUPPS (ORCPT ); Fri, 21 Aug 2015 11:15:18 -0400 Received: from mail-qk0-f182.google.com ([209.85.220.182]:35419 "EHLO mail-qk0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752538AbbHUPPQ (ORCPT ); Fri, 21 Aug 2015 11:15:16 -0400 Date: Fri, 21 Aug 2015 11:15:12 -0400 From: Jerome Glisse To: Dan Williams Cc: Christoph Hellwig , "linux-kernel@vger.kernel.org" , Boaz Harrosh , Rik van Riel , "linux-nvdimm@lists.01.org" , Dave Hansen , david , Ingo Molnar , Linux MM , Ingo Molnar , Mel Gorman , "H. Peter Anvin" , Ross Zwisler , "torvalds@linux-foundation.org" , David Woodhouse Subject: Re: [RFC PATCH 1/7] x86, mm: ZONE_DEVICE for "device memory" Message-ID: <20150821151511.GB3244@gmail.com> References: <20150813031253.36913.29580.stgit@otcpl-skl-sds-2.jf.intel.com> <20150813035005.36913.77364.stgit@otcpl-skl-sds-2.jf.intel.com> <20150814213714.GA3265@gmail.com> <20150815085954.GC21033@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2315 Lines: 44 On Fri, Aug 21, 2015 at 08:02:51AM -0700, Dan Williams wrote: > [ Adding David Woodhouse ] > > On Sat, Aug 15, 2015 at 1:59 AM, Christoph Hellwig wrote: > > On Fri, Aug 14, 2015 at 02:52:15PM -0700, Dan Williams wrote: > >> The idea is that this memory is not meant to be available to the page > >> allocator and should not count as new memory capacity. We're only > >> hotplugging it to get struct page coverage. > > > > This might need a bigger audit of the max_pfn usages. I remember > > architectures using it as a decisions for using IOMMUs or similar. > > We chatted about this at LPC yesterday. The takeaway was that the > max_pfn checks that the IOMMU code does is for checking whether a > device needs an io-virtual mapping to reach addresses above its DMA > limit (if it can't do 64-bit DMA). Given the capacities of persistent > memory it's likely that a device with this limitation already can't > address all of RAM let alone PMEM. So it seems to me that updating > max_pfn for PMEM hotplug does not buy us anything except a few more > opportunities to confuse PMEM as typical RAM. I think it is wrong do not update max_pfn for 3 reasons : - In some case your PMEM memory will end up below current max_pfn value so device doing DMA can confuse your PMEM for regular RAM. - Given the above, not updating PMEM means you are not consistant, ie on some computer PMEM will be DMA addressable by device and on other computer it would not. Because different RAM and PMEM configuration, different bios, ... that cause max_pfn to be below range where PMEM get hotpluged. - Last why would we want to block device to access PMEM directly ? Wouldn't it make sense for some device like say network to read PMEM directly and stream it over the network ? All this happening through IOMMU (i am assuming PCIE network card using IOMMU). Which imply having the IOMMU consider this like regular mapping (ignoring Will Davis recent patchset here that might affect the IOMMU max_pfn test). Cheers, J?r?me -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/