Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S948042AbdDTXHN (ORCPT ); Thu, 20 Apr 2017 19:07:13 -0400 Received: from mail-eopbgr670099.outbound.protection.outlook.com ([40.107.67.99]:61440 "EHLO CAN01-TO1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S947937AbdDTXHK (ORCPT ); Thu, 20 Apr 2017 19:07:10 -0400 From: "Stephen Bates" To: Dan Williams CC: Jerome Glisse , Logan Gunthorpe , Jason Gunthorpe , Benjamin Herrenschmidt , Bjorn Helgaas , "Christoph Hellwig" , Sagi Grimberg , "James E.J. Bottomley" , "Martin K. Petersen" , Jens Axboe , Steve Wise , Max Gurtovoy , Keith Busch , "linux-pci@vger.kernel.org" , linux-scsi , "linux-nvme@lists.infradead.org" , "linux-rdma@vger.kernel.org" , linux-nvdimm , "linux-kernel@vger.kernel.org" Subject: Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory Thread-Topic: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory Thread-Index: AQHStshY8AzeU4AEL0W+Kr5FXh2edaHIkoUAgALGa4CAAB1YgIAACJEAgAAJeACAAAOmgIAAFPmAgABHpwCAAPS1gIAADsiAgAADgICAAAitAIAAApcAgAHV+ID///A5gIAAN9GA Date: Thu, 20 Apr 2017 23:07:06 +0000 Message-ID: References: <20170418164557.GA7181@obsidianresearch.com> <20170418190138.GH7181@obsidianresearch.com> <20170418210339.GA24257@obsidianresearch.com> <1492564806.25766.124.camel@kernel.crashing.org> <20170419155557.GA8497@obsidianresearch.com> <4899b011-bdfb-18d8-ef00-33a1516216a6@deltatee.com> <20170419173225.GA11255@redhat.com> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=raithlin.com; x-originating-ip: [70.65.232.47] x-microsoft-exchange-diagnostics: 1;YTOPR01MB0619;7:T6AQNQ4Wxx/XdEXZpI1roaczvgLXZUZc/UBzWsKemhYtLHPySWKhVOMgYmuBs3N8KCErULHB2ARZofKsB880MsU/sY1m3hFVDufg5GxDDBfOuLy0mQWdxpA4s87j5cf3KrpcmdK2Xeaex7JsuHoT4MSO2O08g0vNtvPVJVjH7hnrfyvBYKpZmJdDtWegDUTDZ2iLS844/MwdNSYQ1I5f78GO3k+PfWdGwthDglZHRlMIe9dCgbVJ9V85WkVm7mft0XnlvBN9ySRsRg4CgfkatESNnRYLC4swHYffCK/H7pEgkzasL4KS7Mfh6M9hPvfLEGdq/mtqUYpRjkt2FF0KlQ== x-ms-office365-filtering-correlation-id: 8d3ae23f-b750-4177-af75-08d48841f74a x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(201703131423075);SRVR:YTOPR01MB0619; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123564025)(2016111802025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(6072148)(6043046);SRVR:YTOPR01MB0619;BCL:0;PCL:0;RULEID:;SRVR:YTOPR01MB0619; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39450400003)(39830400002)(39400400002)(39410400002)(7736002)(76176999)(7416002)(50986999)(54356999)(8676002)(230783001)(25786009)(77096006)(86362001)(81166006)(93886004)(3846002)(6916009)(54906002)(102836003)(6116002)(305945005)(2950100002)(8936002)(4001350100001)(4326008)(6506006)(5660300001)(53936002)(229853002)(36756003)(6512007)(110136004)(6436002)(3280700002)(83716003)(6486002)(2900100001)(38730400002)(2906002)(66066001)(83506001)(33656002)(82746002)(189998001)(3660700001)(6246003)(122556002);DIR:OUT;SFP:1102;SCL:1;SRVR:YTOPR01MB0619;H:YTOPR01MB0619.CANPRD01.PROD.OUTLOOK.COM;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <190261666B639441A95CAFDD7BF19528@CANPRD01.PROD.OUTLOOK.COM> MIME-Version: 1.0 X-OriginatorOrg: raithlin.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2017 23:07:06.6979 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 18519031-7ff4-4cbb-bbcb-c3252d330f4b X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR01MB0619 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v3KN7KSN015118 Content-Length: 934 Lines: 14 >> Yes, this makes sense I think we really just want to distinguish host >> memory or not in terms of the dev_pagemap type. > >> I would like to see mutually exclusive flags for host memory (or not) and persistence (or not). >> > > Why persistence? It has zero meaning to the mm. I like the idea of having properties of the memory in one place. While mm might not use persistence today it may make use certain things that persistence implies (like finite endurance and/or higher write latency) in the future. Also the persistence of the memory must have issues for mm security? Again not addressed today but useful in the future. In addition I am not sure where else would be an appropriate place to put something like a persistence property flag. I know the NVDIMM section of the kernel uses things like NFIT to describe properties of the memory but we don’t yet (to my knowledge) have something similar for IO memory. Stephen