Date:	Tue, 17 Jun 2014 00:24:09 +0200
From:	Andrea Arcangeli <aarcange@...hat.com>
To:	John Stultz <john.stultz@...aro.org>
Cc:	Johannes Weiner <hannes@...xchg.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Android Kernel Team <kernel-team@...roid.com>,
	Robert Love <rlove@...gle.com>, Mel Gorman <mel@....ul.ie>,
	Hugh Dickins <hughd@...gle.com>, Dave Hansen <dave@...1.net>,
	Rik van Riel <riel@...hat.com>,
	Dmitry Adamushko <dmitry.adamushko@...il.com>,
	Neil Brown <neilb@...e.de>, Mike Hommey <mh@...ndium.org>,
	Taras Glek <tglek@...illa.com>, Jan Kara <jack@...e.cz>,
	KOSAKI Motohiro <kosaki.motohiro@...il.com>,
	Michel Lespinasse <walken@...gle.com>,
	Minchan Kim <minchan@...nel.org>,
	Keith Packard <keithp@...thp.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH 0/4] Volatile Ranges (v14 - madvise reborn edition!)

Hello everyone,

On Mon, Jun 16, 2014 at 01:12:41PM -0700, John Stultz wrote:
> On Tue, Jun 3, 2014 at 7:57 AM, Johannes Weiner <hannes@...xchg.org> wrote:
> > That, however, truly is a separate virtual memory feature.  Would it
> > be possible for you to take MADV_FREE and MADV_REVIVE as a base and
> > implement an madvise op that switches the no-page behavior of a VMA
> > from zero-filling to SIGBUS delivery?
> 
> I'll see if I can look into it if I get some time. However, I suspect
> its more likely I'll just have to admit defeat on this one and let
> someone else champion the effort. Interest and reviews have seemingly
> dropped again here and with other work ramping up, I'm not sure if
> I'll be able to justify further work on this. :(

About adding an madvise op that switches the no-page behavior from
zero-filling to SIGBUS delivery (right now only for anonymous vmas but
we can evaluate to extend it) I've mostly completed the
userfaultfd/madvise(MADV_USERFAULT) according to the design I
described earlier. Like we discussed earlier that may fit the bill if
extended to tmpfs? The first preliminary tests just passed last week.

http://git.kernel.org/cgit/linux/kernel/git/andrea/aa.git/?h=userfault

If userfaultfd() isn't instantiated by the process, it only sends a
SIBGUS to the thread accessing the unmapped virtual address
(handle_mm_faults returns VM_FAULT_SIGBUS). The address of the fault
is then available in siginfo->si_addr.

You strictly need a memory externalization thread opening the
userfaultfd and speaking the userfaultfd protocol only if you need to
access the memory also through syscalls or drivers doing GUP
calls. This allows memory mapped in a secondary MMU for example to be
externalized without a single change to the secondary MMU code. The
userfault becomes invisible to
handle_mm_fault/gup()/gup_fast/FOLL_NOWAIT etc.... The only
requirement is that the memory externalization thread never accesses
any memory in the MADV_USERFAULT marked regions (and if it does
because of a bug, the deadlock should be quite apparent by simply
checking the stack trace of the externalization thread blocked in
handle_userfault(), sigkill will then clear it up :). If you close the
userfaultfd the SIGBUS behavior will immediately return for the
MADV_USERFAULT marked regions and any hung task waiting to be waken
will get an immediate SIGBUS.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists