From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb0-f197.google.com (mail-yb0-f197.google.com [209.85.213.197]) by kanga.kvack.org (Postfix) with ESMTP id 845BE6B027C for ; Wed, 19 Oct 2016 16:01:08 -0400 (EDT) Received: by mail-yb0-f197.google.com with SMTP id 206so36600984ybp.4 for ; Wed, 19 Oct 2016 13:01:08 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com. [2607:f8b0:4002:c05::22b]) by mx.google.com with ESMTPS id x84si11802011ywd.331.2016.10.19.13.01.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Oct 2016 13:01:07 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id t192so26327624ywf.0 for ; Wed, 19 Oct 2016 13:01:07 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20161019184028.GB16550@cgy1-donard.priv.deltatee.com> References: <1476826937-20665-1-git-send-email-sbates@raithlin.com> <1476826937-20665-2-git-send-email-sbates@raithlin.com> <20161019184028.GB16550@cgy1-donard.priv.deltatee.com> From: Dan Williams Date: Wed, 19 Oct 2016 13:01:06 -0700 Message-ID: Subject: Re: [PATCH 1/3] memremap.c : Add support for ZONE_DEVICE IO memory with struct pages. Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Stephen Bates Cc: "linux-kernel@vger.kernel.org" , "linux-nvdimm@lists.01.org" , linux-rdma@vger.kernel.org, linux-block@vger.kernel.org, Linux MM , Ross Zwisler , Matthew Wilcox , Jason Gunthorpe , haggaie@mellanox.com, Christoph Hellwig , Jens Axboe , Jonathan Corbet , jim.macdonald@everspin.com, sbates@raithin.com, Logan Gunthorpe On Wed, Oct 19, 2016 at 11:40 AM, Stephen Bates wrote: > On Wed, Oct 19, 2016 at 10:50:25AM -0700, Dan Williams wrote: >> On Tue, Oct 18, 2016 at 2:42 PM, Stephen Bates wrote: >> > From: Logan Gunthorpe >> > >> > We build on recent work that adds memory regions owned by a device >> > driver (ZONE_DEVICE) [1] and to add struct page support for these new >> > regions of memory [2]. >> > >> > 1. Add an extra flags argument into dev_memremap_pages to take in a >> > MEMREMAP_XX argument. We update the existing calls to this function to >> > reflect the change. >> > >> > 2. For completeness, we add MEMREMAP_WT support to the memremap; >> > however we have no actual need for this functionality. >> > >> > 3. We add the static functions, add_zone_device_pages and >> > remove_zone_device pages. These are similar to arch_add_memory except >> > they don't create the memory mapping. We don't believe these need to be >> > made arch specific, but are open to other opinions. >> > >> > 4. dev_memremap_pages and devm_memremap_pages_release are updated to >> > treat IO memory slightly differently. For IO memory we use a combination >> > of the appropriate io_remap function and the zone_device pages functions >> > created above. A flags variable and kaddr pointer are added to struct >> > page_mem to facilitate this for the release function. We also set up >> > the page attribute tables for the mapped region correctly based on the >> > desired mapping. >> > >> >> This description says "what" is being done, but not "why". > > Hi Dan > > We discuss the motivation in the cover letter. > >> >> In the cover letter, "[PATCH 0/3] iopmem : A block device for PCIe >> memory", it mentions that the lack of I/O coherency is a known issue >> and users of this functionality need to be cognizant of the pitfalls. >> If that is the case why do we need support for different cpu mapping >> types than the default write-back cache setting? It's up to the >> application to handle cache cpu flushing similar to what we require of >> device-dax users in the persistent memory case. > > Some of the iopmem hardware we have tested has certain alignment > restrictions on BAR accesses. At the very least we require write > combine mappings for these. We then felt it appropriate to add the > other mappings for the sake of completeness. If the device can support write-combine then it can support bursts, so I wonder why it couldn't support read bursts for cache fills... -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org