Received: by 10.192.165.148 with SMTP id m20csp4333615imm; Mon, 30 Apr 2018 16:40:32 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpfh8/sK3VRj9nzTbSLA6dcEGXzvI2M75Qom5x6nzxY3UTNtdH9YkALrfrT1qGSX5j81ztt X-Received: by 2002:a63:7114:: with SMTP id m20-v6mr11436340pgc.144.1525131632583; Mon, 30 Apr 2018 16:40:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525131632; cv=none; d=google.com; s=arc-20160816; b=WX5MgXUEtjK8V6mwfthnd7Fh7tOqvBW5M8BCPzo4gb8IoL/Gpx0nPZvs0pHXPDFySf cKC9mfLBMkzINmBxJGsLp4akrl2DFa09R7D1XK3JBF1csre0ZMAffVG8ntfBv+1XEHcp qE3SZpOTfkmvchplX+vmKb1RAfmOX5oxpM0FdZLKnwHzY0qyfnQzalDUS820pJXu3ZAY vHOb2Uj0LgDwhKSXHXIinHfeYZoW2nM9tjh1+UJhJRf8XNwXt12+dRvqjuEElBdUBxNy HkUdC9hD4G5feSYnOzNIo3Zm/lZ13CSC0KLDS4sXb57BX+qssrKH50Pi9iXmzldUfhOj X28g== 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 :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=gh/AmkVH84WQ+kH4U7ICWNivHUz1hf92uveoHmDpQ6s=; b=o82dswjm32dki/bUloXjJFHg/jXWeM64EEr3stk8RLfEEaIP2qRsOw+JRfzozn9Y1w rJzpAFxkhsvK0TnwsoqDFzbqHSieUGzFTxa/lFTQiGuJ5GvMMgLdImsX+c0TjyHwHhTc hUatPVseUXJyp+tVDUeWrAhwoEKR8qSqGotoRhwrxYOmIURr2J0YROQCuvo8auoRoirD HZxkkySrBkzb7RbHTPhyi+DuihT+fRsUwbSOiAmeyrq0MnAOYkD7APxzKgm38nWHV0hs sC1bjnoInL7NLBSHnCft36baeF3ewTY0fikrQd3ugRhcGSydgXzSMRnKCpvgUYXi5F9Z bzhA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o68-v6si6981273pga.431.2018.04.30.16.40.18; Mon, 30 Apr 2018 16:40:32 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755633AbeD3XkD (ORCPT + 99 others); Mon, 30 Apr 2018 19:40:03 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:44144 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753900AbeD3XkC (ORCPT ); Mon, 30 Apr 2018 19:40:02 -0400 Received: from akpm3.svl.corp.google.com (unknown [104.133.9.71]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 9571615; Mon, 30 Apr 2018 23:40:01 +0000 (UTC) Date: Mon, 30 Apr 2018 16:40:00 -0700 From: Andrew Morton To: Yang Shi Cc: kirill.shutemov@linux.intel.com, hughd@google.com, mhocko@kernel.org, hch@infradead.org, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Joe Perches Subject: Re: [RFC v5 PATCH] mm: shmem: make stat.st_blksize return huge page size if THP is on Message-Id: <20180430164000.00f92084ecb1876e481c6a11@linux-foundation.org> In-Reply-To: <1524665633-83806-1-git-send-email-yang.shi@linux.alibaba.com> References: <1524665633-83806-1-git-send-email-yang.shi@linux.alibaba.com> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 25 Apr 2018 22:13:53 +0800 Yang Shi wrote: > Since tmpfs THP was supported in 4.8, hugetlbfs is not the only > filesystem with huge page support anymore. tmpfs can use huge page via > THP when mounting by "huge=" mount option. > > When applications use huge page on hugetlbfs, it just need check the > filesystem magic number, but it is not enough for tmpfs. Make > stat.st_blksize return huge page size if it is mounted by appropriate > "huge=" option to give applications a hint to optimize the behavior with > THP. > > Some applications may not do wisely with THP. For example, QEMU may mmap > file on non huge page aligned hint address with MAP_FIXED, which results > in no pages are PMD mapped even though THP is used. Some applications > may mmap file with non huge page aligned offset. Both behaviors make THP > pointless. > > statfs.f_bsize still returns 4KB for tmpfs since THP could be split, and it > also may fallback to 4KB page silently if there is not enough huge page. > Furthermore, different f_bsize makes max_blocks and free_blocks > calculation harder but without too much benefit. Returning huge page > size via stat.st_blksize sounds good enough. > > Since PUD size huge page for THP has not been supported, now it just > returns HPAGE_PMD_SIZE. > > ... > > --- a/mm/shmem.c > +++ b/mm/shmem.c > @@ -571,6 +571,16 @@ static unsigned long shmem_unused_huge_shrink(struct shmem_sb_info *sbinfo, > } > #endif /* CONFIG_TRANSPARENT_HUGE_PAGECACHE */ > > +static inline bool is_huge_enabled(struct shmem_sb_info *sbinfo) > +{ > + if (IS_ENABLED(CONFIG_TRANSPARENT_HUGE_PAGECACHE) && > + (shmem_huge == SHMEM_HUGE_FORCE || sbinfo->huge) && > + shmem_huge != SHMEM_HUGE_DENY) > + return true; > + else > + return false; > +} Nit: we don't need that `else'. Checkpatch normally warns about this, but not in this case. --- a/mm/shmem.c~mm-shmem-make-statst_blksize-return-huge-page-size-if-thp-is-on-fix +++ a/mm/shmem.c @@ -577,8 +577,7 @@ static inline bool is_huge_enabled(struc (shmem_huge == SHMEM_HUGE_FORCE || sbinfo->huge) && shmem_huge != SHMEM_HUGE_DENY) return true; - else - return false; + return false; } /* _