linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Yin Fengwei <fengwei.yin@intel.com>
To: Barry Song <21cnbao@gmail.com>
Cc: Ryan Roberts <ryan.roberts@arm.com>,
	Lance Yang <ioworker0@gmail.com>,
	David Hildenbrand <david@redhat.com>, <akpm@linux-foundation.org>,
	<linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
	<mhocko@suse.com>, <minchan@kernel.org>, <peterx@redhat.com>,
	<shy828301@gmail.com>, <songmuchun@bytedance.com>,
	<wangkefeng.wang@huawei.com>, <zokeefe@google.com>
Subject: Re: [PATCH 1/1] mm/madvise: enhance lazyfreeing with mTHP in madvise_free
Date: Tue, 27 Feb 2024 15:02:22 +0800	[thread overview]
Message-ID: <6ea0020a-8f4b-44d1-a3b2-7c2905d32772@intel.com> (raw)
In-Reply-To: <CAGsJ_4xu1kz5VD-CcNFvP0A1nPKDojV8Gy1HPvNKuQ_RAw=26g@mail.gmail.com>



On 2/27/24 14:40, Barry Song wrote:
> On Tue, Feb 27, 2024 at 7:14 PM Yin Fengwei <fengwei.yin@intel.com> wrote:
>>
>>
>>
>> On 2/27/24 10:17, Barry Song wrote:
>>>> Like if we hit folio which is partially mapped to the range, don't split it but
>>>> just unmap the mapping part from the range. Let page reclaim decide whether
>>>> split the large folio or not (If it's not mapped to any other range,it will be
>>>> freed as whole large folio. If part of it still mapped to other range,page reclaim
>>>> can decide whether to split it or ignore it for current reclaim cycle).
>>> Yes, we can. but we still have to play the ptes check game to avoid adding
>>> folios multiple times to reclaim the list.
>>>
>>> I don't see too much difference between splitting in madvise and splitting
>>> in vmscan.  as our real purpose is avoiding splitting entirely mapped
>>> large folios. for partial mapped large folios, if we split in madvise, then
>>> we don't need to play the game of skipping folios while iterating PTEs.
>>> if we don't split in madvise, we have to make sure the large folio is only
>>> added in reclaimed list one time by checking if PTEs belong to the
>>> previous added folio.
>>
>> If the partial mapped large folio is unmapped from the range, the related PTE
>> become none. How could the folio be added to reclaimed list multiple times?
> 
> in case we have 16 PTEs in a large folio.
> PTE0 present
> PTE1 present
> PTE2 present
> PTE3  none
> PTE4 present
> PTE5 none
> PTE6 present
> ....
> the current code is scanning PTE one by one.
> while scanning PTE0, we have added the folio. then PTE1, PTE2, PTE4, PTE6...
No. Before detect the folio is fully mapped to the range, we can't add folio
to reclaim list because the partial mapped folio shouldn't be added. We can
only scan PTE15 and know it's fully mapped.

So, when scanning PTE0, we will not add folio. Then when hit PTE3, we know
this is a partial mapped large folio. We will unmap it. Then all 16 PTEs
become none.

If the large folio is fully mapped, the folio will be added to reclaim list
after scan PTE15 and know it's fully mapped.

Regards
Yin, Fengwei

> 
> there are all kinds of possibilities for unmapping.
> 
> so what we can do is recording we have added the folio while scanning PTE0,
> then skipping this folios for all other PTEs.
> 
> otherwise, we can split it while scanning PTE0, then we will meet
> different folios
> afterwards.
> 
>>
>>
>> Regards
>> Yin, Fengwei
> 
> Thanks
> Barry


  parent reply	other threads:[~2024-02-27  7:02 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-25 12:32 Lance Yang
2024-02-26  2:38 ` Yin Fengwei
2024-02-26  8:35   ` Lance Yang
2024-02-26 12:57     ` Ryan Roberts
2024-02-26 13:03       ` David Hildenbrand
2024-02-26 13:47         ` Lance Yang
2024-02-26  4:00 ` Barry Song
2024-02-26  8:37   ` Lance Yang
2024-02-26  8:41     ` David Hildenbrand
2024-02-26  8:55       ` Lance Yang
2024-02-26 13:04         ` Ryan Roberts
2024-02-26 13:50           ` Lance Yang
2024-02-27  1:21             ` Barry Song
2024-02-27  1:48               ` Lance Yang
2024-02-27  2:12                 ` Barry Song
2024-02-27  2:15                   ` Lance Yang
2024-02-26 20:49           ` Barry Song
2024-02-27  1:51             ` Yin Fengwei
2024-02-27  2:17               ` Barry Song
2024-02-27  6:14                 ` Yin Fengwei
2024-02-27  6:40                   ` Barry Song
2024-02-27  6:42                     ` Barry Song
2024-02-27  7:02                     ` Yin Fengwei [this message]
2024-02-27  7:11                       ` Barry Song
2024-02-27  7:21                         ` Barry Song
2024-02-27  7:42                           ` Yin Fengwei
2024-02-27  7:54                             ` Barry Song
2024-02-27  8:33                               ` Yin Fengwei
2024-02-27  9:01                                 ` Barry Song
2024-02-26 13:00 ` Ryan Roberts
2024-02-26 13:54   ` Lance Yang

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=6ea0020a-8f4b-44d1-a3b2-7c2905d32772@intel.com \
    --to=fengwei.yin@intel.com \
    --cc=21cnbao@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=ioworker0@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=minchan@kernel.org \
    --cc=peterx@redhat.com \
    --cc=ryan.roberts@arm.com \
    --cc=shy828301@gmail.com \
    --cc=songmuchun@bytedance.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=zokeefe@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox