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

[Minchan Kim]

Hi John,

On Tue, Dec 11, 2012 at 10:45:27AM -0800, John Stultz wrote:
> On 12/10/2012 06:34 PM, Minchan Kim wrote:
> >This still is [RFC v3] because just passed my simple test
> >with TCMalloc tweaking.
> >
> >I hope more inputs from user-space allocator people and test patch
> >with their allocator because it might need design change of arena
> >management design for getting real vaule.
> >
> >Changelog from v2
> >
> >  * Removing madvise(addr, length, MADV_NOVOLATILE).
> >  * add vmstat about the number of discarded volatile pages
> >  * discard volatile pages without promotion in reclaim path
> >
> >This is based on v3.6.
> >
> >- What's the madvise(addr, length, MADV_VOLATILE)?
> >
> >   It's a hint that user deliver to kernel so kernel can *discard*
> >   pages in a range anytime.
> >
> >- What happens if user access page(ie, virtual address) discarded
> >   by kernel?
> >
> >   The user can see zero-fill-on-demand pages as if madvise(DONTNEED).
> >
> >- What happens if user access page(ie, virtual address) doesn't
> >   discarded by kernel?
> >
> >   The user can see old data without page fault.
> >
> >- What's different with madvise(DONTNEED)?
> >
> >   System call semantic
> >
> >   DONTNEED makes sure user always can see zero-fill pages after
> >   he calls madvise while VOLATILE can see zero-fill pages or
> >   old data.
> I still need to really read and understand the patch, but at a high
> level I'm not sure how this works. So does the VOLATILE flag get
> cleared on any access, even if the pages have not been discarded?

No. It is cleared when user try to access discareded pages so
This patch is utter crap. I missed that point.
Thanks for pointing out, John.

Hmm, in the end, we need NOVOLATILE.

> What happens if an application wants to store non-volatile data in
> an area that was once marked volatile. If there was never memory
> pressure, it seems the volatility would persist with no way of
> removing it.

Yes. that's why this patch is crap and I'm insane. :(

> 
> Either way, I feel that with this revision, specifically dropping
> the NOVOLATILE call and the SIGBUS optimization the Mozilla folks
> suggested, your implementation has drifted quite far from the
> concept I'm pushing. While I hope we can still align the underlying
> mm implementation, I might ask that you use a different term for the
> semantics you propose, so we don't add too much confusion to the
> discussion.
> 
> Maybe you could call it DONTNEED_DEFERRED or something?
> 
> In the meantime, I'll be reading your patch in detail and seeing how
> we might be able to combine our differing approaches.

You don't need it. Ignore this patch.
I will rework.

Thanks.

> 
> thanks
> -john
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@xxxxxxxxxx  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>

-- 
Kind regards,
Minchan Kim
--
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/