Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp1412428ybi; Wed, 17 Jul 2019 15:00:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqwFEgsQyMGhqbr7FuQ8b1ZkAB5eJYs2mq1ZMzg3yDMd2A7t/FL9ms0wKbqFDZxGN6MUayeT X-Received: by 2002:a17:902:100a:: with SMTP id b10mr6150556pla.338.1563400820977; Wed, 17 Jul 2019 15:00:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563400820; cv=none; d=google.com; s=arc-20160816; b=olgVdNO66r8iMaxwTuRq3v6kVcuxwMYkq2weJPLjA1YORDDIdOGol4HxBLF38Bs+SA pelLFl3lUlmKzOIqx8YAKx9z+QxtcqLBgi2c6lWb6i4aHdig119jE7EiobmJ1U964d4j nkxjS6FIN5JTtXojtyd1HetlIoQlF75HiwuzI4jjf239EVlzuLXNoe/V/GIHUFcs4ymb UxKOiAbJM4zswX+G8r9ucqDbz2AmKdyGc6Ld2pk7aGAzkReCUslfeE2p+0onUsLfZeFv AD+783dOn3M7+wVhO6+Lk0iclQOy5MorHUjoUaFYi3xfUhFFnmZo9p0YMHNwn8lohM4J XwVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=12zTz4j0UgXqTdL/G4s8a0vSnJAZUXcdtZYJkPHMDzQ=; b=EsLzwlcqvNBTuINHvvuFZ+Im41PDOsda4Yubg5+OtcI3cHpIpvbucohC2PL9rx9+bK LVIvg8RaZ2qflCDsqdF7jvmFtg+KDIu/GB7e5KifG+rTcmv/F9N6wHav1hh7GWYSl2/D QzyX8busB2ELwiwEFBsJI69JD0R3LbxQN9WhQ5G0S0HVV/AmZUwU+Trmjnzq288WeNcx lVv4eEszsdNS2R1rN2OgAbJxuh2OHEI2k+u20eihjbUgx1C5WW/iZndH657ZYgNRrALL Bl9O2umfmJOkxsS9Y+/eyKLtoUKmL2E7p8jDqFwy6dM/Alg0mo8D5Z0u3D5HKj3QKv5u LnRg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id az12si18185527plb.5.2019.07.17.15.00.04; Wed, 17 Jul 2019 15:00:20 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729497AbfGQV7n (ORCPT + 99 others); Wed, 17 Jul 2019 17:59:43 -0400 Received: from out30-132.freemail.mail.aliyun.com ([115.124.30.132]:42479 "EHLO out30-132.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727653AbfGQV7l (ORCPT ); Wed, 17 Jul 2019 17:59:41 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R881e4;CH=green;DM=||false|;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e07486;MF=yang.shi@linux.alibaba.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---0TX9KWw9_1563400771; Received: from e19h19392.et15sqa.tbsite.net(mailfrom:yang.shi@linux.alibaba.com fp:SMTPD_---0TX9KWw9_1563400771) by smtp.aliyun-inc.com(127.0.0.1); Thu, 18 Jul 2019 05:59:38 +0800 From: Yang Shi To: hughd@google.com, kirill.shutemov@linux.intel.com, mhocko@suse.com, vbabka@suse.cz, rientjes@google.com, akpm@linux-foundation.org Cc: yang.shi@linux.alibaba.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [v4 PATCH 0/2] Fix false negative of shmem vma's THP eligibility Date: Thu, 18 Jul 2019 05:59:16 +0800 Message-Id: <1563400758-124759-1-git-send-email-yang.shi@linux.alibaba.com> X-Mailer: git-send-email 1.8.3.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The commit 7635d9cbe832 ("mm, thp, proc: report THP eligibility for each vma") introduced THPeligible bit for processes' smaps. But, when checking the eligibility for shmem vma, __transparent_hugepage_enabled() is called to override the result from shmem_huge_enabled(). It may result in the anonymous vma's THP flag override shmem's. For example, running a simple test which create THP for shmem, but with anonymous THP disabled, when reading the process's smaps, it may show: 7fc92ec00000-7fc92f000000 rw-s 00000000 00:14 27764 /dev/shm/test Size: 4096 kB ... [snip] ... ShmemPmdMapped: 4096 kB ... [snip] ... THPeligible: 0 And, /proc/meminfo does show THP allocated and PMD mapped too: ShmemHugePages: 4096 kB ShmemPmdMapped: 4096 kB This doesn't make too much sense. The shmem objects should be treated separately from anonymous THP. Calling shmem_huge_enabled() with checking MMF_DISABLE_THP sounds good enough. And, we could skip stack and dax vma check since we already checked if the vma is shmem already. The transhuge_vma_suitable() is needed to check vma, but it was only available for shmem THP. The patch 1/2 makes it available for all kind of THPs and does some code duplication cleanup, so it is made a separate patch. Changelog: v4: * Moved transhuge_vma_suitable() to include/linux/huge_mm.h and regroup some functions in linux/include/mm.h. Per Hugh Dickins. * Added Hugh’s Acked-by to patch 2/2. v3: * Check if vma is suitable for allocating THP per Hugh Dickins. * Fixed smaps output alignment and documentation per Hugh Dickins. v2: * Check VM_NOHUGEPAGE per Michal Hocko. Yang Shi (2): mm: thp: make transhuge_vma_suitable available for anonymous THP mm: thp: fix false negative of shmem vma's THP eligibility Documentation/filesystems/proc.txt | 4 ++-- fs/proc/task_mmu.c | 3 ++- include/linux/huge_mm.h | 23 +++++++++++++++++++++++ include/linux/mm.h | 34 +++++++++++++++++----------------- mm/huge_memory.c | 11 ++++++++--- mm/memory.c | 13 ------------- mm/shmem.c | 3 +++ 7 files changed, 55 insertions(+), 36 deletions(-)