On Tue 21-05-19 19:52:56, Minchan Kim wrote: > On Tue, May 21, 2019 at 09:06:38AM +0200, Oleksandr Natalenko wrote: > > Hi. > > > > On Tue, May 21, 2019 at 08:50:00AM +0200, Michal Hocko wrote: > > > On Tue 21-05-19 08:36:28, Oleksandr Natalenko wrote: > > > [...] > > > > Regarding restricting the hints, I'm definitely interested in having > > > > remote MADV_MERGEABLE/MADV_UNMERGEABLE. But, OTOH, doing it via remote > > > > madvise() introduces another issue with traversing remote VMAs reliably. > > > > IIUC, one can do this via userspace by parsing [s]maps file only, which > > > > is not very consistent, and once some range is parsed, and then it is > > > > immediately gone, a wrong hint will be sent. > > > > > > > > Isn't this a problem we should worry about? > > > > > > See http://lkml.kernel.org/r/20190520091829.GY6836@xxxxxxxxxxxxxx > > > > Oh, thanks for the pointer. > > > > Indeed, for my specific task with remote KSM I'd go with map_files > > instead. This doesn't solve the task completely in case of traversal > > through all the VMAs in one pass, but makes it easier comparing to a > > remote syscall. > > I'm wondering how map_files can solve your concern exactly if you have > a concern about the race of vma unmap/remap even there are anonymous > vma which map_files doesn't support. See http://lkml.kernel.org/r/20190521105503.GQ32329@xxxxxxxxxxxxxx -- Michal Hocko SUSE Labs
