From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 4697E22423829 for ; Thu, 1 Mar 2018 12:57:34 -0800 (PST) Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w21KxwMj063462 for ; Thu, 1 Mar 2018 16:03:42 -0500 Received: from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109]) by mx0b-001b2d01.pphosted.com with ESMTP id 2geqw22y1w-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 01 Mar 2018 16:03:41 -0500 Received: from localhost by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 1 Mar 2018 21:03:39 -0000 Subject: Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory From: Benjamin Herrenschmidt Date: Fri, 02 Mar 2018 08:03:30 +1100 In-Reply-To: References: <20180228234006.21093-1-logang@deltatee.com> <1519876489.4592.3.camel@kernel.crashing.org> <1519876569.4592.4.camel@au1.ibm.com> Mime-Version: 1.0 Message-Id: <1519938210.4592.30.camel@au1.ibm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: benh@au1.ibm.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Dan Williams Cc: Jens Axboe , Keith Busch , Oliver OHalloran , Alex Williamson , linux-nvdimm , linux-rdma , linux-pci@vger.kernel.org, Linux Kernel Mailing List , linux-nvme@lists.infradead.org, linux-block@vger.kernel.org, =?ISO-8859-1?Q?J=E9r=F4me?= Glisse , Jason Gunthorpe , Bjorn Helgaas , Max Gurtovoy , Christoph Hellwig List-ID: On Thu, 2018-03-01 at 11:21 -0800, Dan Williams wrote: > > > The devm_memremap_pages() infrastructure allows placing the memmap in > "System-RAM" even if the hotplugged range is in PCI space. So, even if > it is an issue on some configurations, it's just a simple adjustment > to where the memmap is placed. Actually can you explain a bit more here ? devm_memremap_pages() doesn't take any specific argument about what to do with the memory. It does create the vmemmap sections etc... but does so by calling arch_add_memory(). So __add_memory() isn't called, which means the pages aren't added to the linear mapping. Then you manually add them to ZONE_DEVICE. Am I correct ? In that case, they indeed can't be used as normal memory pages, which is good, and if they are indeed not in the linear mapping, then there is no caching issues. However, what happens if anything calls page_address() on them ? Some DMA ops do that for example, or some devices might ... This is all quite convoluted with no documentation I can find that explains the various expectations. So the question is are those pages landing in the linear mapping, and if yes, by what code path ? The next question is if we ever want that to work on ppc64, we need a way to make this fit in our linear mapping and map it non-cachable, which will require some wrangling on how we handle that mapping. Cheers, Ben. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm