On 22.10.19 19:55, Matt Sickler wrote:
Right now, ZONE_DEVICE memory is always set PG_reserved. We want to change that.
The pages are obtained via get_user_pages_fast(). I assume, these could be ZONE_DEVICE pages. Let's just exclude them as well explicitly.
I'm not sure what ZONE_DEVICE pages are, but these pages are normal system RAM, typically HugePages (but not always).
ZONE_DEVICE, a.k.a. devmem, are pages that bypass the pagecache (e.g.,
DAX) completely and will therefore never get swapped. These pages are
not managed by any page allocator (especially not the buddy), they are
rather "directly mapped device memory".
E.g., a NVDIMM. It is mapped into the physical address space similar to
ordinary RAM (a DIMM). Any write to such a PFN will directly end up on
the target device. In contrast to a DIMM, the memory is persistent
accross reboots.
Now, if you mmap such an NVDIMM into a user space process, you will end
up with ZONE_DEVICE pages as part of the user space mapping (VMA).
get_user_pages_fast() on this memory will result in "struct pages" that
belong to ZONE_DEVICE. This is where this patch comes into play.
This patch makes sure that there is absolutely no change once we stop
setting these ZONE_DEVICE pages PG_reserved. E.g., AFAIK, setting a
ZONE_DEVICE page dirty does not make too much sense (never swapped).
Yes, it might not be a likely setup, however, it is possible. In this
series I collect all places that *could* be affected. If that change is
really needed has to be decided. I can see that the two staging drivers
I have patches for might be able to just live with the change - but then
we talked about it and are aware of the change.
Thanks!
--
Thanks,
David / dhildenb
