From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1757704AbbCCWFx (ORCPT <rfc822;w@1wt.eu>);
	Tue, 3 Mar 2015 17:05:53 -0500
Received: from cantor2.suse.de ([195.135.220.15]:47098 "EHLO mx2.suse.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1755270AbbCCWFw (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 3 Mar 2015 17:05:52 -0500
Message-ID: <54F6303C.5080806@suse.cz>
Date: Tue, 03 Mar 2015 23:05:48 +0100
From: Vlastimil Babka <vbabka@suse.cz>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Eric B Munson <emunson@akamai.com>
CC: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        Peter Zijlstra <peterz@infradead.org>,
        Christoph Lameter <cl@linux.com>, Thomas Gleixner <tglx@linutronix.de>,
        Andrew Morton <akpm@linux-foundation.org>,
        Hugh Dickins <hughd@google.com>, Mel Gorman <mgorman@suse.de>,
        Roland Dreier <roland@kernel.org>, Sean Hefty <sean.hefty@intel.com>,
        Hal Rosenstock <hal.rosenstock@gmail.com>,
        Mike Marciniszyn <infinipath@intel.com>
Subject: Re: Resurrecting the VM_PINNED discussion
References: <20150303174105.GA3295@akamai.com> <54F5FEE0.2090104@suse.cz> <20150303184520.GA4996@akamai.com> <54F617A2.8040405@suse.cz> <20150303210150.GA6995@akamai.com> <20150303215258.GB6995@akamai.com>
In-Reply-To: <20150303215258.GB6995@akamai.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 03/03/2015 10:52 PM, Eric B Munson wrote:
> On Tue, 03 Mar 2015, Eric B Munson wrote:
> 
>> On Tue, 03 Mar 2015, Vlastimil Babka wrote:
>> 
>> > On 03/03/2015 07:45 PM, Eric B Munson wrote:
>> > > On Tue, 03 Mar 2015, Vlastimil Babka wrote:
>> > > 
>> > > Agreed.  But as has been discussed in the threads around the VM_PINNED
>> > > work, there are people that are relying on the fact that VM_LOCKED
>> > > promises no minor faults.  Which is why the behavoir has remained.
>> > 
>> > At least in the VM_PINNED thread after last lsf/mm, I don't see this mentioned.
>> > I found no references to mlocking in compaction.c, and in migrate.c there's just
>> > mlock_migrate_page() with comment:
>> > 
>> > /*
>> >  * mlock_migrate_page - called only from migrate_page_copy() to
>> >  * migrate the Mlocked page flag; update statistics.
>> >  */
>> > 
>> > It also passes TTU_IGNORE_MLOCK to try_to_unmap(). So what am I missing? Where
>> > is this restriction?
>> > 
>> 
>> I spent quite some time looking for it as well, it is in vmscan.c
>> 
>> int __isolate_lru_page(struct page *page, isolate_mode_t mode)
>> {
>> ...
>>         /* Compaction should not handle unevictable pages but CMA can do so */
>>         if (PageUnevictable(page) && !(mode & ISOLATE_UNEVICTABLE))
>>                 return ret;
>> ...
>> 
>> 
> 
> And that demonstrates that I haven't spent enough time with this code,
> that isn't the restriction because when this is called from compaction.c
> the mode is set to ISOLATE_UNEVICTABLE.  So back to reading the code.

No, you were correct and thanks for the hint. It's only ISOLATE_UNEVICTABLE from
isolate_migratepages_range(), which is CMA, not regular compaction.
But I wonder, can we change this even after VM_PINNED is introduced, if existing
code depends on "no minor faults in mlocked areas", whatever the docs say? On
the other hand, compaction is not the only source of migrations. I wonder what
the NUMA balancing does (not) about mlocked areas...