Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751983AbdHGXFK (ORCPT <rfc822;w@1wt.eu>);
        Mon, 7 Aug 2017 19:05:10 -0400
Received: from mga14.intel.com ([192.55.52.115]:59579 "EHLO mga14.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751875AbdHGXFJ (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 7 Aug 2017 19:05:09 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.41,340,1498546800"; 
   d="scan'208";a="1203092850"
From: "Huang\, Ying" <ying.huang@intel.com>
To: Christopher Lameter <cl@linux.com>
Cc: "Huang\, Ying" <ying.huang@intel.com>,
        Andrew Morton <akpm@linux-foundation.org>, <linux-mm@kvack.org>,
        <linux-kernel@vger.kernel.org>, Andrea Arcangeli <aarcange@redhat.com>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Nadia Yvette Chambers <nyc@holomorphy.com>,
        Michal Hocko <mhocko@suse.com>, Jan Kara <jack@suse.cz>,
        Matthew Wilcox <willy@linux.intel.com>,
        Hugh Dickins <hughd@google.com>, Minchan Kim <minchan@kernel.org>,
        Shaohua Li <shli@fb.com>
Subject: Re: [PATCH -mm] mm: Clear to access sub-page last when clearing huge page
References: <20170807072131.8343-1-ying.huang@intel.com>
        <alpine.DEB.2.20.1708071343030.19915@nuc-kabylake>
Date: Tue, 08 Aug 2017 07:05:03 +0800
In-Reply-To: <alpine.DEB.2.20.1708071343030.19915@nuc-kabylake> (Christopher
        Lameter's message of "Mon, 7 Aug 2017 13:46:37 -0500")
Message-ID: <87a83bgesg.fsf@yhuang-mobile.sh.intel.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=ascii
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1201
Lines: 36

Christopher Lameter <cl@linux.com> writes:

> On Mon, 7 Aug 2017, Huang, Ying wrote:
>
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -4374,9 +4374,31 @@ void clear_huge_page(struct page *page,
>>  	}
>>
>>  	might_sleep();
>> -	for (i = 0; i < pages_per_huge_page; i++) {
>> +	VM_BUG_ON(clamp(addr_hint, addr, addr +
>> +			(pages_per_huge_page << PAGE_SHIFT)) != addr_hint);
>> +	n = (addr_hint - addr) / PAGE_SIZE;
>> +	if (2 * n <= pages_per_huge_page) {
>> +		base = 0;
>> +		l = n;
>> +		for (i = pages_per_huge_page - 1; i >= 2 * n; i--) {
>> +			cond_resched();
>> +			clear_user_highpage(page + i, addr + i * PAGE_SIZE);
>> +		}
>
> I really like the idea behind the patch but this is not clearing from last
> to first byte of the huge page.
>
> What seems to be happening here is clearing from the last page to the
> first page and I would think that within each page the clearing is from
> first byte to last byte. Maybe more gains can be had by really clearing
> from last to first byte of the huge page instead of this jumping over 4k
> addresses?

Yes.  That is a good idea.  I will experiment it via changing the
direction to clear in clear_user_highpage().

Best Regards,
Huang, Ying