Am 2022-02-11 um 11:39 schrieb David Hildenbrand:
On 11.02.22 17:15, David Hildenbrand wrote:
On 01.02.22 16:48, Alex Sierra wrote:
Device memory that is cache coherent from device and CPU point of view. This is used on platforms that have an advanced system bus (like CAPI or CXL). Any page of a process can be migrated to such memory. However, no one should be allowed to pin such memory so that it can always be evicted.
Signed-off-by: Alex Sierra alex.sierra@amd.com Acked-by: Felix Kuehling Felix.Kuehling@amd.com Reviewed-by: Alistair Popple apopple@nvidia.com
So, I'm currently messing with PageAnon() pages and CoW semantics ... all these PageAnon() ZONE_DEVICE variants don't necessarily make my life easier but I'm not sure yet if they make my life harder. I hope you can help me understand some of that stuff.
- What are expected CoW semantics for DEVICE_COHERENT?
I assume we'll share them just like other PageAnon() pages during fork() readable, and the first sharer writing to them receives an "ordinary" !ZONE_DEVICE copy.
So this would be just like DEVICE_EXCLUSIVE CoW handling I assume, just that we don't have to go through the loop of restoring a device exclusive entry?
- How are these pages freed to clear/invalidate PageAnon() ?
I assume for PageAnon() ZONE_DEVICE pages we'll always for via free_devmap_managed_page(), correct?
- FOLL_PIN
While you write "no one should be allowed to pin such memory", patch #2 only blocks FOLL_LONGTERM. So I assume we allow ordinary FOLL_PIN and you might want to be a bit more precise?
... I'm pretty sure we cannot FOLL_PIN DEVICE_PRIVATE pages, but can we FILL_PIN DEVICE_EXCLUSIVE pages? I strongly assume so?
Thanks for any information.
(digging a bit more, I realized that device exclusive pages are not actually/necessarily ZONE_DEVICE pages -- so I assume DEVICE_COHERENT will be the actual first PageAnon() ZONE_DEVICE pages that can be present in a page table.)
I think DEVICE_GENERIC pages can also be mapped in the page table. In fact, the first version of our patches attempted to add migration support to DEVICE_GENERIC. But we were convinced to create a new ZONE_DEVICE page type for our use case instead.
Regards, Felix