All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Kravetz <mike.kravetz@oracle.com>
To: Miaohe Lin <linmiaohe@huawei.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] hugetlbfs: remove meaningless variable avoid_reserve
Date: Tue, 19 Jan 2021 10:41:58 -0800	[thread overview]
Message-ID: <2900fea0-e77c-8c6a-1529-c95ded5319e6@oracle.com> (raw)
In-Reply-To: <20210116092644.42697-1-linmiaohe@huawei.com>

Please CC Andrew on hugetlb patches as they need to go through his tree.

On 1/16/21 1:26 AM, Miaohe Lin wrote:
> The variable avoid_reserve is meaningless because we never changed its
> value and just passed it to alloc_huge_page(). So remove it to make code
> more clear that in hugetlbfs_fallocate, we never avoid reserve when alloc
> hugepage yet.

One might argue that using a named variable makes the call to alloc_huge_page
more clear.  I do not disagree with the change,  However, there are some
subtle reasons why alloc_huge_page is called with 'avoid_reserve = 0' from
fallocate.  Therefore, I would prefer that a comment be added above the call
in addition to this change.  See below.

> 
> Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
> ---
>  fs/hugetlbfs/inode.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
> index 88751e35e69d..23ad6ed8b75f 100644
> --- a/fs/hugetlbfs/inode.c
> +++ b/fs/hugetlbfs/inode.c
> @@ -680,7 +680,6 @@ static long hugetlbfs_fallocate(struct file *file, int mode, loff_t offset,
>  		 */
>  		struct page *page;
>  		unsigned long addr;
> -		int avoid_reserve = 0;
>  
>  		cond_resched();
>  
> @@ -717,7 +716,7 @@ static long hugetlbfs_fallocate(struct file *file, int mode, loff_t offset,
>  		}
>  
>  		/* Allocate page and add to page cache */

Perhaps, change comment to read:

		/*
		 * Allocate page without setting the avoid_reserve argument.
		 * There certainly are no reserves associated with the
		 * pseudo_vma.  However, there could be shared mappings with
		 * reserves for the file at the inode level.  If we fallocate
		 * pages in these areas, we need to consume the reserves
		 * to keep reservation accounting consistent.
		 */

-- 
Mike Kravetz

> -		page = alloc_huge_page(&pseudo_vma, addr, avoid_reserve);
> +		page = alloc_huge_page(&pseudo_vma, addr, 0);
>  		hugetlb_drop_vma_policy(&pseudo_vma);
>  		if (IS_ERR(page)) {
>  			mutex_unlock(&hugetlb_fault_mutex_table[hash]);
> 

  parent reply	other threads:[~2021-01-19 19:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-16  9:26 [PATCH] hugetlbfs: remove meaningless variable avoid_reserve Miaohe Lin
2021-01-16  9:39 ` Souptick Joarder
2021-01-16  9:39   ` Souptick Joarder
2021-01-18  9:58 ` David Hildenbrand
2021-01-19 18:41 ` Mike Kravetz [this message]
2021-01-20  2:10   ` Miaohe Lin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2900fea0-e77c-8c6a-1529-c95ded5319e6@oracle.com \
    --to=mike.kravetz@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=linmiaohe@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.