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 S1756548AbdLOKAc (ORCPT <rfc822;w@1wt.eu>);
        Fri, 15 Dec 2017 05:00:32 -0500
Received: from mail-wm0-f47.google.com ([74.125.82.47]:40899 "EHLO
        mail-wm0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1756452AbdLOKA1 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 15 Dec 2017 05:00:27 -0500
X-Google-Smtp-Source: ACJfBovXbz71Ip0SwqLwAeT+VA2cY4WuQp6YAdBoqudP0n9iRMmWHVLHb/PNh4TSZxPeRymOjOoguA==
Date: Fri, 15 Dec 2017 13:00:24 +0300
From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Nitin Gupta <nitin.m.gupta@oracle.com>
Cc: linux-mm@kvack.org, steven.sistare@oracle.com,
        Andrew Morton <akpm@linux-foundation.org>,
        Ingo Molnar <mingo@kernel.org>, Mel Gorman <mgorman@suse.de>,
        Nadav Amit <namit@vmware.com>, Minchan Kim <minchan@kernel.org>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Vegard Nossum <vegard.nossum@oracle.com>,
        "Levin, Alexander (Sasha Levin)" <alexander.levin@verizon.com>,
        Michal Hocko <mhocko@suse.com>, David Rientjes <rientjes@google.com>,
        Vlastimil Babka <vbabka@suse.cz>, SeongJae Park <sj38.park@gmail.com>,
        Shaohua Li <shli@fb.com>,
        "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Mike Rapoport <rppt@linux.vnet.ibm.com>,
        Anshuman Khandual <khandual@linux.vnet.ibm.com>,
        Rik van Riel <riel@redhat.com>,
        Ross Zwisler <ross.zwisler@linux.intel.com>, Jan Kara <jack@suse.cz>,
        Dave Jiang <dave.jiang@intel.com>,
        =?iso-8859-1?B?Suly9G1l?= Glisse <jglisse@redhat.com>,
        Matthew Wilcox <willy@linux.intel.com>,
        Hugh Dickins <hughd@google.com>, Tobin C Harding <me@tobin.cc>,
        open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: Reduce memory bloat with THP
Message-ID: <20171215100024.gxuijdovjhkugarz@node.shutemov.name>
References: <1513301359-117568-1-git-send-email-nitin.m.gupta@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1513301359-117568-1-git-send-email-nitin.m.gupta@oracle.com>
User-Agent: NeoMutt/20171208
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Dec 14, 2017 at 05:28:52PM -0800, Nitin Gupta wrote:
> Currently, if the THP enabled policy is "always", or the mode
> is "madvise" and a region is marked as MADV_HUGEPAGE, a hugepage
> is allocated on a page fault if the pud or pmd is empty.  This
> yields the best VA translation performance, but increases memory
> consumption if some small page ranges within the huge page are
> never accessed.
> 
> An alternate behavior for such page faults is to install a
> hugepage only when a region is actually found to be (almost)
> fully mapped and active.  This is a compromise between
> translation performance and memory consumption.  Currently there
> is no way for an application to choose this compromise for the
> page fault conditions above.
> 
> With this change, when an application issues MADV_DONTNEED on a
> memory region, the region is marked as "space-efficient". For
> such regions, a hugepage is not immediately allocated on first
> write.  Instead, it is left to the khugepaged thread to do
> delayed hugepage promotion depending on whether the region is
> actually mapped and active. When application issues
> MADV_HUGEPAGE, the region is marked again as non-space-efficient
> wherein hugepage is allocated on first touch.

I think this would be NAK. At least in this form.

What performance testing have you done? Any numbers?

Making whole vma "space_efficient" just because somebody freed one page
from it is just wrong. And there's no way back after this.

> 
> Orabug: 26910556

Wat?

-- 
 Kirill A. Shutemov