[CC += linux-api, since this is an API change.]

Hi John,

A couple of other questions that occurred to me...

What are the expected/planned semantics of volatile ranges for mlocked
pages? I noticed that Minchan's patch series
(https://lwn.net/Articles/522154/) gives an error on attempt to mark
locked pages as volatile (which seems sensible). I didn't see anything
similar in your patches. Perhaps it's not easy to do because of the
non-VMA-based implementation? Something to think about.

On Wed, Oct 3, 2012 at 12:38 AM, John Stultz [off-list ref] wrote:

On 10/02/2012 12:39 AM, NeilBrown wrote:

quoted

On Fri, 28 Sep 2012 23:16:30 -0400 John Stultz [off-list ref]
wrote:

  For example, allowing sub-page volatile region seems to be above and
beyond
  the call of duty.  You cannot mmap sub-pages, so why should they be
volatile?

Although if someone marked a page and a half as volatile, would it be
reasonable to throw away the second half of that second page? That seems
unexpected to me. So we're really only marking the whole pages specified as
volatlie,  similar to how FALLOC_FL_PUNCH_HOLE behaves.

But if it happens that the adjacent range is also a partial page, we can
coalesce them possibly into an purgable whole page. I think it makes sense,
especially from a userland point of view and wasn't really complicated to
add.

I must confess that I'm puzzled by this facility to lock sub-page
range ranges as well. What's the use case? What I'm thinking is: the
goal of volatile ranges is to help improve system performance by
freeing up a (sizeable) block of pages. Why then would the user care
too much about marking with sub-page granularity, or that such ranges
might be merged? After all, the system calls to do this marking are
expensive, and so for performance reasons, I suppose that a process
would like to keep those system calls to a minimum.

[...]

quoted

  I think discarding whole ranges at a time is very sensible, and so
merging
  adjacent ranges is best avoided.  If you require page-aligned ranges
this
  becomes trivial - is that right?

True. If we avoid coalescing non-whole page ranges, keeping non-overlapping
ranges independent is fairly easy.

Regarding coalescing of adjacent ranges. Here's one possible argument
against it (Jake Edge alerted me to this). If an application marked
adjacent ranges using separate system calls, that might be an
indication that the application intends to to have different access
patterns against the two ranges: one frequent, the other rare. In that
case, I suppose it would be better if the ranges were not merged.

Cheers,

Michael

-- 
Michael Kerrisk Linux man-pages maintainer;
http://www.kernel.org/doc/man-pages/