[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SN1PR12MB070353A173C65D77A2868A79FEB40@SN1PR12MB0703.namprd12.prod.outlook.com>
Date: Tue, 22 Nov 2016 22:21:12 +0000
From: "Sagalovitch, Serguei" <Serguei.Sagalovitch@....com>
To: Dan Williams <dan.j.williams@...el.com>,
Daniel Vetter <daniel@...ll.ch>
CC: Dave Hansen <dave.hansen@...ux.intel.com>,
"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"Kuehling, Felix" <Felix.Kuehling@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"Koenig, Christian" <Christian.Koenig@....com>,
"Sander, Ben" <ben.sander@....com>,
"Suthikulpanit, Suravee" <Suravee.Suthikulpanit@....com>,
"Deucher, Alexander" <Alexander.Deucher@....com>,
"Blinzer, Paul" <Paul.Blinzer@....com>,
"Linux-media@...r.kernel.org" <Linux-media@...r.kernel.org>
Subject: Re: Enabling peer to peer device transactions for PCIe devices
> 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?
Powered by blists - more mailing lists