From: David Hildenbrand <david@redhat.com>
To: Rong Qianfeng <11065417@vivo.com>
Cc: opensource.kernel@vivo.com, Rong Qianfeng <rongqianfeng@vivo.com>,
vbabka@suse.cz, mgorman@techsingularity.net,
Andrew Morton <akpm@linux-foundation.org>,
Mike Rapoport <rppt@kernel.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Zi Yan <ziy@nvidia.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: Skip the reserved bootmem for compaction
Date: Tue, 3 Sep 2024 11:56:29 +0200 [thread overview]
Message-ID: <f86cf28c-c274-4ba9-8a4d-8d221ad94d62@redhat.com> (raw)
In-Reply-To: <c4ec57e5-49e1-413f-a1e2-e258c628c55f@vivo.com>
On 03.09.24 09:14, Rong Qianfeng wrote:
> Hi David,
>
> Thanks very much for the detailed comments and explanations!
>
> 在 2024/9/2 21:45, David Hildenbrand 写道:
>> On 02.09.24 14:24, Rong Qianfeng wrote:
>>> Reserved pages are basically non-lru pages. This kind of memory can't be
>>> used as migration sources and targets, skip it can bring some
>>> performance
>>> benefits.
>>
>> Any numbers? :)
>
> I am still thinking about how to design test cases. If you have any good
> suggestions, please tell me. Thank you very much.
Well, you claim that it can bring performance improvement, so it's your
responsibility to prove it :)
I have real idea how you could measure that, sorry.
This change will make the code more complicated (and as raised, there
are some corner cases not handled yet). So it's better worth the price. :)
[...]
>
>>
>>
>> What about free_reserved_page() ? There might be more, though
>> (kimage_free_pages()). You have to take a look at all functions where we
>> clear PageReserved.
>
> Thanks for your reminder, I found that I missed a lot of functions.
> Maybe a better choice is to clear PB_migrate_skip in free_reserved_page()
> to reduce the amount of modification.
Hm, maybe. At least for free_reserved_area() it would be beneficial to
minimize the per-page handling.
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2024-09-03 9:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-02 12:24 Rong Qianfeng
2024-09-02 13:45 ` David Hildenbrand
2024-09-03 7:14 ` Rong Qianfeng
2024-09-03 9:56 ` David Hildenbrand [this message]
2024-09-04 11:13 ` Mel Gorman
2024-09-04 11:59 ` Rong Qianfeng
2024-09-04 15:38 ` Mike Rapoport
2024-09-05 3:10 ` Rong Qianfeng
2024-09-04 14:54 ` kernel test robot
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=f86cf28c-c274-4ba9-8a4d-8d221ad94d62@redhat.com \
--to=david@redhat.com \
--cc=11065417@vivo.com \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=opensource.kernel@vivo.com \
--cc=rongqianfeng@vivo.com \
--cc=rppt@kernel.org \
--cc=vbabka@suse.cz \
--cc=ziy@nvidia.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
all inboxes | Powered by JetHome®