linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: John Stultz <john.stultz@linaro.org>
To: Minchan Kim <minchan@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	Arun Sharma <asharma@fb.com>,
	sanjay@google.com, Paul Turner <pjt@google.com>,
	David Rientjes <rientjes@google.com>,
	Christoph Lameter <cl@linux.com>,
	Android Kernel Team <kernel-team@android.com>,
	Robert Love <rlove@google.com>, Mel Gorman <mel@csn.ul.ie>,
	Hugh Dickins <hughd@google.com>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Rik van Riel <riel@redhat.com>,
	Dave Chinner <david@fromorbit.com>, Neil Brown <neilb@suse.de>,
	Mike Hommey <mh@glandium.org>, Taras Glek <tglek@mozilla.com>,
	KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [RFC v3] Support volatile range for anon vma
Date: Tue, 11 Dec 2012 10:45:27 -0800	[thread overview]
Message-ID: <50C77F47.10601@linaro.org> (raw)
In-Reply-To: <1355193255-7217-1-git-send-email-minchan@kernel.org>

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

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.

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>

  parent reply	other threads:[~2012-12-11 18:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-11  2:34 [RFC v3] Support volatile range for anon vma Minchan Kim
2012-12-11  2:41 ` Minchan Kim
2012-12-11  7:17   ` Mike Hommey
2012-12-11  7:37     ` Minchan Kim
2012-12-11  7:59       ` Mike Hommey
2012-12-11  8:11         ` Minchan Kim
2012-12-11  8:29           ` Mike Hommey
2012-12-11  8:45             ` Minchan Kim
2012-12-12  6:43   ` Wanpeng Li
2012-12-12  6:43   ` Wanpeng Li
2012-12-12  8:17     ` Wanpeng Li
2012-12-12  8:17     ` Wanpeng Li
     [not found]     ` <50c83d9b.49fe2a0a.57ee.ffff90b0SMTPIN_ADDED_BROKEN@mx.google.com>
2012-12-12  8:42       ` Minchan Kim
     [not found]   ` <50c827cb.ce98320a.7d38.ffffad3fSMTPIN_ADDED_BROKEN@mx.google.com>
2012-12-12  8:15     ` Minchan Kim
2012-12-11 18:45 ` John Stultz [this message]
2012-12-11 23:21   ` Minchan Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50C77F47.10601@linaro.org \
    --to=john.stultz@linaro.org \
    --cc=akpm@linux-foundation.org \
    --cc=asharma@fb.com \
    --cc=cl@linux.com \
    --cc=dave@linux.vnet.ibm.com \
    --cc=david@fromorbit.com \
    --cc=hughd@google.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kernel-team@android.com \
    --cc=kosaki.motohiro@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=mh@glandium.org \
    --cc=minchan@kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=neilb@suse.de \
    --cc=pjt@google.com \
    --cc=riel@redhat.com \
    --cc=rientjes@google.com \
    --cc=rlove@google.com \
    --cc=sanjay@google.com \
    --cc=tglek@mozilla.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).