lkml.org 
[lkml]   [2019]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC 4/7] mm: factor out madvise's core functionality
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@dhcp22.suse.cz
>
> 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.

>
> --
> Best regards,
> Oleksandr Natalenko (post-factum)
> Senior Software Maintenance Engineer

\
 
 \ /
  Last update: 2019-05-21 12:53    [W:0.110 / U:5.828 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site