From: David Hildenbrand <david@redhat.com>
To: Miaohe Lin <linmiaohe@huawei.com>
Cc: ying.huang@intel.com, hch@lst.de, dhowells@redhat.com,
cl@linux.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, mike.kravetz@oracle.com,
naoya.horiguchi@nec.com, Minchan Kim <minchan@kernel.org>
Subject: Re: [PATCH v2 2/4] mm/migration: remove unneeded lock page and PageMovable check
Date: Thu, 12 May 2022 09:10:20 +0200 [thread overview]
Message-ID: <c566dc2c-fc70-e410-5272-767fa28cbba4@redhat.com> (raw)
In-Reply-To: <924de987-202b-a97e-e6d2-6bdab530f190@huawei.com>
>> If PG_isolated is still set, it will get cleared in the buddy when
>> freeing the page via
>>
>> page->flags &= ~PAGE_FLAGS_CHECK_AT_PREP;
>
> Yes, check_free_page only complains about flags belonging to PAGE_FLAGS_CHECK_AT_FREE and PG_isolated
> will be cleared in the buddy when freeing the page. But it might not be a good idea to reply on this ?
> IMHO, it should be better to clear the PG_isolated explicitly ourselves.
I think we can pretty much rely on this handling in the buddy :)
>
>>
>>>
>>>>
>>>>
>>>> Also, I am not sure how reliable that page count check is here: if we'd
>>>> have another speculative reference to the page, we might see
>>>> "page_count(page) > 1" and not take that path, although the previous
>>>> owner released the last reference.
>>>
>>> IIUC, there should not be such speculative reference. The driver should have taken care
>>> of it.
>>
>> How can you prevent any kind of speculative references?
>>
>> See isolate_movable_page() as an example, which grabs a speculative
>> reference to then find out that the page is already isolated by someone
>> else, to then back off.
>
> You're right. isolate_movable_page will be an speculative references case. But the page count check here
> is just an optimization. If we encounter speculative references, it still works with useless effort of
> migrating to be released page.
Not really. The issue is that PAGE_FLAGS_CHECK_AT_FREE contains
PG_active and PG_unevictable.
We only clear those 2 flags if "page_count(page) == 1". Consequently,
with a speculative reference, we'll run into the check_free_page_bad()
when dropping the last reference.
This is just shaky. Special casing on "page_count(page) == 1" for
detecting "was this freed by the owner" is not 100% water proof.
In an ideal world, we'd just get rid of that whole block of code and let
the actual freeing code clear PG_active and PG_unevictable. But that
would require changes to free_pages_prepare().
Now I do wonder, if we ever even have PG_active or PG_unevictable still
set when the page was freed by the owner in this code. IOW, maybe that
is dead code as well and we can just remove the whole shaky
"page_count(page) == 1" code block.
Ccing Minchan, who added clearing of the pageflags at that point.
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2022-05-12 7:10 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-25 13:27 [PATCH v2 0/4] A few cleanup and fixup patches for migration Miaohe Lin
2022-04-25 13:27 ` [PATCH v2 1/4] mm/migration: reduce the rcu lock duration Miaohe Lin
2022-04-29 9:54 ` David Hildenbrand
2022-05-09 3:14 ` Miaohe Lin
2022-05-24 12:36 ` Miaohe Lin
2022-05-06 3:23 ` ying.huang
2022-05-09 3:20 ` Miaohe Lin
2022-04-25 13:27 ` [PATCH v2 2/4] mm/migration: remove unneeded lock page and PageMovable check Miaohe Lin
2022-04-29 10:07 ` David Hildenbrand
2022-05-09 8:51 ` Miaohe Lin
2022-05-11 15:23 ` David Hildenbrand
2022-05-12 2:25 ` Miaohe Lin
2022-05-12 7:10 ` David Hildenbrand [this message]
2022-05-12 13:26 ` Miaohe Lin
2022-05-12 16:50 ` David Hildenbrand
2022-05-16 2:44 ` Miaohe Lin
2022-05-31 11:59 ` David Hildenbrand
2022-05-31 12:37 ` Miaohe Lin
2022-06-01 10:31 ` David Hildenbrand
2022-06-02 7:40 ` Miaohe Lin
2022-06-02 8:47 ` David Hildenbrand
2022-06-07 2:20 ` Miaohe Lin
2022-06-08 10:05 ` David Hildenbrand
2022-06-08 13:31 ` Miaohe Lin
2022-05-24 12:47 ` Miaohe Lin
2022-04-25 13:27 ` [PATCH v2 3/4] mm/migration: return errno when isolate_huge_page failed Miaohe Lin
2022-04-29 10:08 ` David Hildenbrand
2022-05-09 8:03 ` Miaohe Lin
2022-04-29 11:36 ` Muchun Song
2022-05-09 3:23 ` Miaohe Lin
2022-05-09 4:21 ` Muchun Song
2022-05-09 7:51 ` Miaohe Lin
2022-04-25 13:27 ` [PATCH v2 4/4] mm/migration: fix potential pte_unmap on an not mapped pte Miaohe Lin
2022-04-29 9:48 ` David Hildenbrand
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=c566dc2c-fc70-e410-5272-767fa28cbba4@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=dhowells@redhat.com \
--cc=hch@lst.de \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=minchan@kernel.org \
--cc=naoya.horiguchi@nec.com \
--cc=ying.huang@intel.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;
as well as URLs for NNTP newsgroup(s).