linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mike Kravetz <mike.kravetz@oracle.com>
To: Muchun Song <songmuchun@bytedance.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	Andi Kleen <ak@linux.intel.com>,
	mhocko@suse.cz, Linux Memory Management List <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [External] Re: [PATCH 2/6] hugetlbfs: fix cannot migrate the fallocated HugeTLB page
Date: Tue, 5 Jan 2021 14:27:08 -0800	[thread overview]
Message-ID: <24d35764-46b9-4234-3266-91232ac9103b@oracle.com> (raw)
In-Reply-To: <CAMZfGtXApP2k5AWK5ff5TWh+nkY1bHKbMimj4faFC8u6bUzMCQ@mail.gmail.com>

On 1/4/21 6:44 PM, Muchun Song wrote:
> On Tue, Jan 5, 2021 at 6:40 AM Mike Kravetz <mike.kravetz@oracle.com> wrote:
>>
>> On 1/3/21 10:58 PM, Muchun Song wrote:
>>> Because we only can isolate a active page via isolate_huge_page()
>>> and hugetlbfs_fallocate() forget to mark it as active, we cannot
>>> isolate and migrate those pages.
>>>
>>> Fixes: 70c3547e36f5 (hugetlbfs: add hugetlbfs_fallocate())
>>> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
>>> ---
>>>  fs/hugetlbfs/inode.c | 5 +++--
>>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> Good catch.  This is indeed an issue.
>>
>>>
>>> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
>>> index b5c109703daa..2aceb085d202 100644
>>> --- a/fs/hugetlbfs/inode.c
>>> +++ b/fs/hugetlbfs/inode.c
>>> @@ -737,10 +737,11 @@ static long hugetlbfs_fallocate(struct file *file, int mode, loff_t offset,
>>>
>>>               /*
>>>                * unlock_page because locked by add_to_page_cache()
>>> -              * page_put due to reference from alloc_huge_page()
>>> +              * put_page() (which is in the putback_active_hugepage())
>>> +              * due to reference from alloc_huge_page()
>>
>> Thanks for fixing the comment.
>>
>>>                */
>>>               unlock_page(page);
>>> -             put_page(page);
>>> +             putback_active_hugepage(page);
>>
>> I'm curious why you used putback_active_hugepage() here instead of simply
>> calling set_page_huge_active() before the put_page()?
>>
>> When the page was allocated, it was placed on the active list (alloc_huge_page).
>> Therefore, the hugetlb_lock locking and list movement should not be necessary.
> 
> I agree with you. Because set_page_huge_active is not exported (static
> function). Only exporting set_page_huge_active seems strange (leaving
> clear_page_huge_active not export). This is just my opinion. What's
> yours, Mike?

I'm thinking that we should export (make external) set_page_huge_active.
We can leave clear_page_huge_active as static and just add something to
the commit log noting that there are no external users.

My primary reason for doing this is to eliminate the extra and unnecessary
per-page lock/unlock cycle.  I believe there are some applications that
use fallocate to pre-allocate very large hugetlbfs files.  They may notice
the extra overhead.
-- 
Mike Kravetz


  reply	other threads:[~2021-01-05 22:29 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-04  6:58 [PATCH 1/6] mm: migrate: do not migrate HugeTLB page whose refcount is one Muchun Song
2021-01-04  6:58 ` [PATCH 2/6] hugetlbfs: fix cannot migrate the fallocated HugeTLB page Muchun Song
2021-01-04 22:38   ` Mike Kravetz
2021-01-05  2:44     ` [External] " Muchun Song
2021-01-05 22:27       ` Mike Kravetz [this message]
2021-01-06  2:57         ` Muchun Song
2021-01-04  6:58 ` [PATCH 3/6] mm: hugetlb: fix a race between freeing and dissolving the page Muchun Song
2021-01-05  0:00   ` Mike Kravetz
2021-01-05  2:55     ` [External] " Muchun Song
2021-01-05 23:22       ` Mike Kravetz
2021-01-06  6:05         ` Muchun Song
2021-01-05  6:12     ` Muchun Song
2021-01-04  6:58 ` [PATCH 4/6] mm: hugetlb: add return -EAGAIN for dissolve_free_huge_page Muchun Song
2021-01-05  1:32   ` Mike Kravetz
2021-01-05  3:14     ` [External] " Muchun Song
2021-01-05  3:46       ` Muchun Song
2021-01-06  0:07         ` Mike Kravetz
2021-01-05  6:37   ` HORIGUCHI NAOYA(堀口 直也)
2021-01-05  7:10     ` [External] " Muchun Song
2021-01-05  7:30       ` HORIGUCHI NAOYA(堀口 直也)
2021-01-04  6:58 ` [PATCH 5/6] mm: hugetlb: fix a race between isolating and freeing page Muchun Song
2021-01-05  1:42   ` Mike Kravetz
2021-01-04  6:58 ` [PATCH 6/6] mm: hugetlb: remove VM_BUG_ON_PAGE from page_huge_active Muchun Song
2021-01-05  1:50   ` Mike Kravetz
2021-01-04 22:17 ` [PATCH 1/6] mm: migrate: do not migrate HugeTLB page whose refcount is one Mike Kravetz
2021-01-05 16:58 ` David Hildenbrand
2021-01-05 18:04   ` Yang Shi
2021-01-05 18:05     ` David Hildenbrand
2021-01-05 18:04 ` Yang Shi
2021-01-06 16:11 ` Michal Hocko
2021-01-06 16:12   ` Michal Hocko

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=24d35764-46b9-4234-3266-91232ac9103b@oracle.com \
    --to=mike.kravetz@oracle.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=songmuchun@bytedance.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox