Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756201AbcKVWVU (ORCPT ); Tue, 22 Nov 2016 17:21:20 -0500 Received: from mail-cys01nam02on0054.outbound.protection.outlook.com ([104.47.37.54]:31872 "EHLO NAM02-CY1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755360AbcKVWVR (ORCPT ); Tue, 22 Nov 2016 17:21:17 -0500 X-Greylist: delayed 4041 seconds by postgrey-1.27 at vger.kernel.org; Tue, 22 Nov 2016 17:21:17 EST From: "Sagalovitch, Serguei" To: Dan Williams , Daniel Vetter CC: Dave Hansen , "linux-nvdimm@lists.01.org" , "linux-rdma@vger.kernel.org" , "linux-pci@vger.kernel.org" , "Kuehling, Felix" , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "Koenig, Christian" , "Sander, Ben" , "Suthikulpanit, Suravee" , "Deucher, Alexander" , "Blinzer, Paul" , "Linux-media@vger.kernel.org" Subject: Re: Enabling peer to peer device transactions for PCIe devices Thread-Topic: Enabling peer to peer device transactions for PCIe devices Thread-Index: AdJENuonJPasaqxFT7iHs+MJbpSfBgAtPueA//+5dwCAAGUcgIAAAqOA//+zAACAAFumgIAABQCAgAAPjho= Date: Tue, 22 Nov 2016 22:21:12 +0000 Message-ID: References: <75a1f44f-c495-7d1e-7e1c-17e89555edba@amd.com> , In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Serguei.Sagalovitch@amd.com; x-originating-ip: [132.245.39.245] x-microsoft-exchange-diagnostics: 1;SN1PR12MB0320;7:TbnA8EnKV74M5Yh7s20INDi6DA4Hp69Sid9V/1SQECFs17BtgORYZ3uCWotyEu9pMjmZcXGZRo6J9LZhlpm+MQ7p2aSrOaMkiKq/J0blTkBMPazPpuf2Al7cYhVSXTdNvNYNV2JxfPCi7T/HhZt+OHL3W22LbXBtIiRhmza65eaoXQls6XM77+rkTHNLTjr2LCmxY7uRA4NZwCZXdSPLCRb1XLImQSkURq6zo6b3CDiAOzP6gk3wTktKFtYxo+xvEFDOoDGm4k6KsRhC8WX5D8UTHu5/K3+PM4ITdd9haYKHwyPzNZBtC6UIiaJrm+/g+CeT022hQlFhXIZcRG1wzps3dG3cmoe/ltH4sfKoZm4=;20:0rzsE3bNDA32qaUjMCW6818QjNvpB0QtwVXepb4Yli4tC27RLkSFOlMmkXHNTB/i3rNiiDvxrO4K7f7rJ9xEhr9taQDqX9yuQodRspzP0uuVd5qnajTYRnBC5GWk4n7WOhivdjREDL1JDM9uEoU/MjtgaZ0P7FFbQ4lOQr7UMV37mqsYu0ML5bLQ1ibPmtRMxzQSaipNbDKF92P1pHzWeQesPLijGUl0BfywCjhxYYQF9sJlC6ZhJAS1Isr2y+Er x-forefront-antispam-report: SFV:SKI;SCL:-1SFV:NSPM;SFS:(10009020)(6009001)(7916002)(199003)(189002)(33656002)(2906002)(8676002)(76576001)(68736007)(3280700002)(3660700001)(38730400001)(8936002)(122556002)(5001770100001)(93886004)(2900100001)(97736004)(77096005)(6116002)(5660300001)(3846002)(66066001)(92566002)(86362001)(189998001)(9686002)(102836003)(7696004)(7846002)(99286002)(7736002)(106356001)(229853002)(81166006)(105586002)(81156014)(6506003)(101416001)(74316002)(2950100002)(305945005)(76176999)(4326007)(54356999)(50986999);DIR:OUT;SFP:1101;SCL:1;SRVR:SN1PR12MB0320;H:SN1PR12MB0703.namprd12.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; x-ms-office365-filtering-correlation-id: 22d0dbed-2735-475b-f0ac-08d41325de38 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN1PR12MB0320; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6060326)(6040307)(6045199)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(6061324)(6072148);SRVR:SN1PR12MB0320;BCL:0;PCL:0;RULEID:;SRVR:SN1PR12MB0320; x-forefront-prvs: 0134AD334F spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2016 22:21:12.7342 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR12MB0320 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 quoted-printable to 8bit by mail.home.local id uAMMLOKi008582 Content-Length: 352 Lines: 11 >?I don't think we should be using numa distance to reverse engineer a >?certain allocation behavior.? The latency data should be truthful, but >?you're right we'll need a mechanism to keep general purpose >?allocations out of that range by default.? Just to clarify: Do you propose/thinking to utilize NUMA API for? such (VRAM) allocations?