lkml.org 
[lkml]   [2012]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC v3] Support volatile range for anon vma
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@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

--
Kind regards,
Minchan Kim


\
 
 \ /
  Last update: 2012-12-12 00:41    [W:0.058 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site