All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Usama Arif <usamaarif642@gmail.com>,
	akpm@linux-foundation.org, linux-mm@kvack.org
Cc: hannes@cmpxchg.org, riel@surriel.com, shakeel.butt@linux.dev,
	roman.gushchin@linux.dev, yuzhao@google.com, baohua@kernel.org,
	ryan.roberts@arm.com, rppt@kernel.org, willy@infradead.org,
	cerasuolodomenico@gmail.com, corbet@lwn.net,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	kernel-team@meta.com, Shuang Zhai <zhais@google.com>
Subject: Re: [PATCH 3/6] mm: free zapped tail pages when splitting isolated thp
Date: Mon, 5 Aug 2024 11:00:12 +0200	[thread overview]
Message-ID: <73bbee97-ff58-4518-8dcf-e1da07906b45@redhat.com> (raw)
In-Reply-To: <6622b7b4-e558-4d14-bc72-33e8008b06ec@gmail.com>

On 04.08.24 21:02, Usama Arif wrote:
> 
> 
> On 30/07/2024 16:14, David Hildenbrand wrote:
>> On 30.07.24 14:46, Usama Arif wrote:
>>> From: Yu Zhao <yuzhao@google.com>
>>>
>>> If a tail page has only two references left, one inherited from the
>>> isolation of its head and the other from lru_add_page_tail() which we
>>> are about to drop, it means this tail page was concurrently zapped.
>>> Then we can safely free it and save page reclaim or migration the
>>> trouble of trying it.
>>>
>>> Signed-off-by: Yu Zhao <yuzhao@google.com>
>>> Tested-by: Shuang Zhai <zhais@google.com>
>>> Signed-off-by: Usama Arif <usamaarif642@gmail.com>
>>> ---
>>>    mm/huge_memory.c | 26 ++++++++++++++++++++++++++
>>>    1 file changed, 26 insertions(+)
>>>
>>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>>> index 0167dc27e365..76a3b6a2b796 100644
>>> --- a/mm/huge_memory.c
>>> +++ b/mm/huge_memory.c
>>> @@ -2923,6 +2923,8 @@ static void __split_huge_page(struct page *page, struct list_head *list,
>>>        unsigned int new_nr = 1 << new_order;
>>>        int order = folio_order(folio);
>>>        unsigned int nr = 1 << order;
>>> +    LIST_HEAD(pages_to_free);
>>> +    int nr_pages_to_free = 0;
>>>          /* complete memcg works before add pages to LRU */
>>>        split_page_memcg(head, order, new_order);
>>> @@ -3007,6 +3009,24 @@ static void __split_huge_page(struct page *page, struct list_head *list,
>>>            if (subpage == page)
>>>                continue;
>>>            folio_unlock(new_folio);
>>> +        /*
>>> +         * If a tail page has only two references left, one inherited
>>> +         * from the isolation of its head and the other from
>>> +         * lru_add_page_tail() which we are about to drop, it means this
>>> +         * tail page was concurrently zapped. Then we can safely free it
>>> +         * and save page reclaim or migration the trouble of trying it.
>>> +         */
>>> +        if (list && page_ref_freeze(subpage, 2)) {
>>> +            VM_BUG_ON_PAGE(PageLRU(subpage), subpage);
>>> +            VM_BUG_ON_PAGE(PageCompound(subpage), subpage);
>>> +            VM_BUG_ON_PAGE(page_mapped(subpage), subpage);
>>> +
>>
>> No VM_BUG_*, VM_WARN is good enough.
>>
>>> +            ClearPageActive(subpage);
>>> +            ClearPageUnevictable(subpage);
>>> +            list_move(&subpage->lru, &pages_to_free);
>>
>> Most checks here should operate on new_folio instead of subpage.
>>
>>
> Do you mean instead of doing the PageLRU, PageCompound and page_mapped check on the subpage, there should be checks on new_folio?
> If new_folio is a large folio, then it could be that only some of the subpages were zapped?

We do a:

struct folio *new_folio = page_folio(subpage);

Then:

PageLRU() will end up getting translated to 
folio_test_lru(page_folio(subpage))

page_mapped() will end up getting translated to
folio_mapped(page_folio(subpage))

PageCompound() is essentially a folio_test_large() check.

So what stops us from doing

VM_WARN_ON_ONCE_FOLIO(folio_test_lru(new_folio), new_folio);
VM_WARN_ON_ONCE_FOLIO(folio_test_large(new_folio), new_folio);
VM_WARN_ON_ONCE_FOLIO(folio_mapped(new_folio), new_folio);

folio_clear_active(new_folio);
folio_clear_unevictable(new_folio);
...

?

The page_ref_freeze() should make sure that we don't have a tail page of
a large folio. Tail pages would have a refcount of 0.

Or what am I missing?

> 
> Could do below if subpage makes sense
> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 3305e6d0b90e..abfcd4b7cbba 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -3041,9 +3041,9 @@ static void __split_huge_page(struct page *page, struct list_head *list,
>                   * and save page reclaim or migration the trouble of trying it.
>                   */
>                  if (list && page_ref_freeze(subpage, 2)) {
> -                       VM_BUG_ON_PAGE(PageLRU(subpage), subpage);
> -                       VM_BUG_ON_PAGE(PageCompound(subpage), subpage);
> -                       VM_BUG_ON_PAGE(page_mapped(subpage), subpage);
> +                       VM_WARN_ON_ONCE_PAGE(PageLRU(subpage), subpage);
> +                       VM_WARN_ON_ONCE_PAGE(PageCompound(subpage), subpage);
> +                       VM_WARN_ON_ONCE_PAGE(page_mapped(subpage), subpage);
>   
>                          ClearPageActive(subpage);
>                          ClearPageUnevictable(subpage);
> 

-- 
Cheers,

David / dhildenb


  reply	other threads:[~2024-08-05  9:00 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-30 12:45 [PATCH 0/6] mm: split underutilized THPs Usama Arif
2024-07-30 12:45 ` [PATCH 1/6] Revert "memcg: remove mem_cgroup_uncharge_list()" Usama Arif
2024-07-30 12:45 ` [PATCH 2/6] Revert "mm: remove free_unref_page_list()" Usama Arif
2024-07-30 12:46 ` [PATCH 3/6] mm: free zapped tail pages when splitting isolated thp Usama Arif
2024-07-30 15:14   ` David Hildenbrand
2024-08-04 19:02     ` Usama Arif
2024-08-05  9:00       ` David Hildenbrand [this message]
2024-08-06  9:58         ` Usama Arif
2024-07-30 12:46 ` [PATCH 4/6] mm: don't remap unused subpages " Usama Arif
2024-07-30 18:07   ` Rik van Riel
2024-07-31 17:08     ` Usama Arif
2024-07-30 12:46 ` [PATCH 5/6] mm: add selftests to split_huge_page() to verify unmap/zap of zero pages Usama Arif
2024-07-30 18:10   ` Rik van Riel
2024-08-01  4:45   ` kernel test robot
2024-08-06 22:02     ` Usama Arif
2024-07-30 12:46 ` [PATCH 6/6] mm: split underutilized THPs Usama Arif
2024-07-30 13:59   ` Randy Dunlap
2024-07-30 14:35 ` [PATCH 0/6] " David Hildenbrand
2024-07-30 15:14   ` Usama Arif
2024-07-30 15:19     ` Usama Arif
2024-07-30 16:11       ` David Hildenbrand
2024-07-30 17:22         ` Usama Arif
2024-07-30 20:25           ` David Hildenbrand
2024-07-31 17:01             ` Usama Arif
2024-07-31 17:51               ` David Hildenbrand
2024-07-31 20:41                 ` Usama Arif
2024-08-01  6:36                   ` David Hildenbrand
2024-08-04 23:04                     ` Usama Arif
2024-08-06 17:17                       ` Usama Arif
2024-08-06 17:30                         ` David Hildenbrand
2024-08-06 17:28                     ` Johannes Weiner
2024-08-06 17:33                       ` David Hildenbrand
2024-08-01  6:09 ` Yu Zhao
2024-08-01 15:47   ` David Hildenbrand
2024-08-04 21:54     ` Yu Zhao
2024-08-05  1:32       ` Rik van Riel
2024-08-05 19:51         ` Yu Zhao
2024-08-01 16:22   ` Usama Arif
2024-08-01 16:27     ` David Hildenbrand
2024-08-04 19:10       ` Usama Arif
2024-08-04 23:32       ` Yu Zhao
2024-08-04 23:23     ` Yu Zhao
2024-08-06 11:18       ` Usama Arif
2024-08-06 17:38   ` Johannes Weiner
2024-08-06 18:06     ` Yu Zhao
2024-08-06 19:54       ` Johannes Weiner
2024-08-06 20:53         ` Yu Zhao

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=73bbee97-ff58-4518-8dcf-e1da07906b45@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=cerasuolodomenico@gmail.com \
    --cc=corbet@lwn.net \
    --cc=hannes@cmpxchg.org \
    --cc=kernel-team@meta.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=riel@surriel.com \
    --cc=roman.gushchin@linux.dev \
    --cc=rppt@kernel.org \
    --cc=ryan.roberts@arm.com \
    --cc=shakeel.butt@linux.dev \
    --cc=usamaarif642@gmail.com \
    --cc=willy@infradead.org \
    --cc=yuzhao@google.com \
    --cc=zhais@google.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 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.