Messages in this thread | | | Date | Tue, 26 Sep 2017 18:32:41 +0200 | From | Michal Hocko <> | Subject | Re: [PATCH] mm/device-public-memory: Enable move_pages() to stat device memory |
| |
On Tue 26-09-17 09:47:10, Reza Arbab wrote: > On Tue, Sep 26, 2017 at 01:37:07PM +0000, Michal Hocko wrote: > > On Fri 22-09-17 15:13:56, Reza Arbab wrote: > > > The move_pages() syscall can be used to find the numa node where a page > > > currently resides. This is not working for device public memory pages, > > > which erroneously report -EFAULT (unmapped or zero page). > > > > > > Enable by adding a FOLL_DEVICE flag for follow_page(), which > > > move_pages() will use. This could be done unconditionally, but adding a > > > flag seems like a safer change. > > > > I do not understand purpose of this patch. What is the numa node of a > > device memory? > > Well, using hmm_devmem_pages_create() it is added to this node: > > nid = dev_to_node(device); > if (nid < 0) > nid = numa_mem_id();
OK, but do all the HMM devices have concept of NUMA affinity? From the code you are pasting they do not have to...
> I understand it's minimally useful information to userspace, but the memory > does have a nid and move_pages() is supposed to be able to return what that > is. I ran into this using a testcase which tries to verify that user > addresses were correctly migrated to coherent device memory. > > That said, I'm okay with dropping this if you don't think it's worthwhile.
I am just worried that we allow information which is not generally sensible and I am also not sure what the userspace can actually do with that information. -- Michal Hocko SUSE Labs
| |