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@xxxxxxxxx. 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, 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>