Re: [RFC v2] Support volatile range for anon vma

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/04/2012 11:01 PM, Minchan Kim wrote:
Hi John,

On Tue, Dec 04, 2012 at 11:13:40AM -0800, John Stultz wrote:

I don't think the problem is when vmas being marked VM_VOLATILE are
being merged, its that when we mark the vma as *non-volatile*, and
remove the VM_VOLATILE flag we merge the non-volatile vmas with
neighboring vmas. So preserving the purged flag during that merge is
important. Again, the example I used to trigger this was an
alternating pattern of volatile and non volatile vmas, then marking
the entire range non-volatile (though sometimes in two overlapping
passes).
If I understand correctly, you mean following as.

chunk1 = mmap(8M)
chunk2 = chunk1 + 2M;
chunk3 = chunk2 + 2M
chunk4 = chunk3 + 2M

madvise(chunk1, 2M, VOLATILE);
madvise(chunk4, 2M, VOLATILE);

/*
  * V : volatile vma
  * N : non volatile vma
  * So Now vma is VNVN.
  */
And chunk4 is purged.

int ret = madvise(chunk1, 8M, NOVOLATILE);
ASSERT(ret == 1);
/* And you expect VNVN->N ?*/

Right?

Yes. That's exactly right.

If so, why should non-volatile function semantic allow it which cross over
non-volatile areas in a range? I would like to fail such case because
in case of MADV_REMOVE, it fails in the middle of operation if it encounter
VM_LOCKED.

What do you think about it?
Right, so I think this issue is maybe a problematic part of the VMA based approach. While marking an area as nonvolatile twice might not make a lot of sense, I think userland applications would not appreciate the constraint that madvise(VOLATILE/NONVOLATILE) calls be made in perfect pairs of identical sizes.

For instance, if a browser has rendered a web page, but the page is so large that only a sliding window/view of that page is visible at one time, it may want to mark the regions not currently in the view as volatile. So it would be nice (albeit naive) for that application that when the view location changed, it would just mark the new region as non-volatile, and any region not in the current view as volatile. This would be easier then trying to calculate the diff of the old view region boundaries vs the new and modifying only the ranges that changed. Granted, doing so might be more efficient, but I'm not sure we can be sure every similar case would be more efficient.

So in my mind, double-clearing a flag should be allowed (as well as double-setting), as well as allowing for setting/clearing overlapping regions.

Aside from if the behavior should be allowed or not, the error mode of madvise is problematic as well, since failures can happen mid way through the operation, leaving the vmas in the range specified inconsistent. Since usually its only advisory, such inconsistent states aren't really problematic, and repeating the last action is probably fine.

The problem with NOVOLATILE's purged state, with vmas, is that if we hit an error mid-way through, its hard to figure out what the state of the pages are for the range specified. Some of them could have been purged and set to non-volatile, while some may not be purged, and still left volatile. You can't just repeat the last action and get a sane result (as we lose the purged flag state).

With my earlier fallocate implementations, I tried to avoid this by making any memory allocations that might be required before making any state changes, so there wasn't a chance for a partial failure from -ENOMEM. (It was also simpler because in my own range management code there were only volatile ranges, non-volatility was simply the absence of a volatile range. With vmas we have to manage both volatile and nonvolatile vmas). I'm not sure how this could be done with the vma method other then by maybe reworking the merge/split logic, but I'm wary of mucking with that too much as I know its performance sensitive.

Your thoughts?  Am I just being too set in my way of thinking here?

thanks
-john

--
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>


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]