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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
