Re: [PATCH 0/3] Volatile Ranges (v11)

[Dave Hansen]

On 03/18/2014 05:24 AM, Michal Hocko wrote:
> On Fri 14-03-14 11:33:30, John Stultz wrote:
> [...]
>> Volatile ranges provides a method for userland to inform the kernel that
>> a range of memory is safe to discard (ie: can be regenerated) but
>> userspace may want to try access it in the future.  It can be thought of
>> as similar to MADV_DONTNEED, but that the actual freeing of the memory
>> is delayed and only done under memory pressure, and the user can try to
>> cancel the action and be able to quickly access any unpurged pages. The
>> idea originated from Android's ashmem, but I've since learned that other
>> OSes provide similar functionality.
> 
> Maybe I have missed something (I've only glanced through the patches)
> but it seems that marking a range volatile doesn't alter neither
> reference bits nor position in the LRU. I thought that a volatile page
> would be moved to the end of inactive LRU with the reference bit
> dropped. Or is this expectation wrong and volatility is not supposed to
> touch page aging?

I'm not really convinced it should alter the aging.  Things could
potentially go in and out of volatile state frequently, and requiring
aging means we've got to go after them page-by-page or pte-by-pte at
best.  That doesn't seem like something we want to do in a path we want
to be fast.

Why not just let normal page aging deal with them?  It seems to me like
like trying to infer intended lru position from volatility is the wrong
thing.  It's quite possible we'd have two pages in the same range that
we want in completely different parts of the LRU.  Maybe the structure
has a hot page and a cold one, and we would ideally want the cold one
swapped out and not the hot one.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/