Messages in this thread | | | Date | Wed, 23 Sep 2015 12:21:42 +0200 | From | Pavel Machek <> | Subject | Re: HMM (Heterogeneous Memory Management) v10 |
| |
Hi!
> Minor fixes since last post (1), apply on top of 4.2-rc6 done > that because conflict in infiniband are harder to solve then
is.
> conflict with mm tree. > > Tree with the patchset: > git://people.freedesktop.org/~glisse/linux hmm-v10 branch > > Previous cover letter : > > > > HMM (Heterogeneous Memory Management) is an helper layer for device > that want to mirror a process address space into their own mmu. Main > target is GPU but other hardware, like network device can take also
GPU, ... devices
> use HMM. > > There is two side to HMM, first one is mirroring of process address
There are
> space on behalf of a device. HMM will manage a secondary page table > for the device and keep it synchronize with the CPU page table. HMM
synchronized
> also do DMA mapping on behalf of the device (which would allow new
also does
> kind of optimization further down the road (2)).
kinds of optimalizations
> Second side is allowing to migrate process memory to device memory
,
> where device memory is unmappable by the CPU. Any CPU access will > trigger special fault that will migrate memory back. This patchset > does not deal with remote memory migration. > > > Why doing this ? > > Mirroring a process address space is mandatory with OpenCL 2.0 and > with other GPU compute API. OpenCL 2.0 allow different level of
APIs... allows
> implementation and currently only the lowest 2 are supported on > Linux. To implement the highest level, where CPU and GPU access > can happen concurently and are cache coherent, HMM is needed, or > something providing same functionality, for instance through > platform hardware. > > Hardware solution such as PCIE ATS/PASID is limited to mirroring > system memory and does not provide way to migrate memory to device > memory (which offer significantly more bandwidth up to 10 times
, up to
> faster than regular system memory with discret GPU, also have
discrete?
> lower latency than PCIE transaction).
> Current CPU with GPU on same die (AMD or Intel) use the ATS/PASID > and for Intel a special level of cache (backed by a large pool of > fast memory). > > For foreeseeable futur, discrete GPU will remain releveant as they
future .. GPUs
> can have a large quantity of faster memory than integrated GPU. > > Thus we believe HMM will allow to leverage discret GPU memory in
allow us... discrete
> a transparent fashion to the application, with minimum disruption > to the linux kernel mm code. Also HMM can work along hardware > solution such as PCIE ATS/PASID (leaving regular case to ATS/PASID > while HMM handles the migrated memory case).
Best regards, Pavel
-- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
| |