Re: [PATCH 05/14] vrange: Add new vrange(2) system call

[Minchan Kim <minchan@kernel.org>]

On Mon, Oct 07, 2013 at 06:24:49PM -0700, H. Peter Anvin wrote:
> On 10/07/2013 05:13 PM, Minchan Kim wrote:
> >>
> >> The point is that MADV_DONTNEED is very similar in that sense,
> >> especially if allowed to be lazy.  It makes a lot of sense to permit
> >> both scrubbing modes orthogonally.
> >>
> >> The point you're making has to do with withdrawal of permission to flush
> >> on demand, which is a result of having the lazy mode (ongoing
> >> permission) and having to be able to withdraw such permission.
> > 
> > I'm sorry I could not understand what you wanted to say.
> > Could you elaborate a bit?
> > 
> 
> Basically, you need this because of MADV_LAZY or the equivalent, so it
> would be applicable to a similar variant of madvise().
> 
> As such I would suggest that an madvise4() call would be appropriate.
> 
> 	-hpa

Maybe, int madvise5(addr, length, MADV_DONTNEED|MADV_LAZY|MADV_SIGBUS,
        &purged, &ret);

Another reason to make it hard is that madvise(2) is tight coupled with
with vmas split/merge. It needs mmap_sem's write-side lock and it hurt
anon-vrange test performance much heavily and userland might want to
make volatile range with small unit like "page size" so it's undesireable
to make it with vma. Then, we should filter out to avoid vma split/merge
in implementation if only MADV_LAZY case? Doable but it could make code
complicated and lost consistency with other variant of madvise.

I think it would be better to implement MADV_FREE if you really want
MADV_LAZY(http://www.unix.com/man-page/FreeBSD/2/madvise/) which is
differnt with volatile range and vrange is more advanced function, IMHO
because MADV_FREE's cost would be proporational to range size due to
page table/page descriptor operations.

-- 
Kind regards,
Minchan Kim