[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 <john.stultz@xxxxxxxxxx> wrote: > On 10/02/2012 12:39 AM, NeilBrown wrote: >> >> On Fri, 28 Sep 2012 23:16:30 -0400 John Stultz <john.stultz@xxxxxxxxxx> >> 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. [...] >> 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/ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>