linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Barry Song <21cnbao@gmail.com>
To: Yin Fengwei <fengwei.yin@intel.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:17:30 +1300	[thread overview]
Message-ID: <CAGsJ_4wx72KOazANBvnGcjdZse8W9+PW5_fspP9=QuX3X_7msg@mail.gmail.com> (raw)
In-Reply-To: <19758162-be5f-4dc4-b316-77b0115d12ce@intel.com>

On Tue, Feb 27, 2024 at 2:51 PM Yin Fengwei <fengwei.yin@intel.com> wrote:
>
>
>
> On 2/27/24 04:49, Barry Song wrote:
> > On Tue, Feb 27, 2024 at 2:04 AM Ryan Roberts <ryan.roberts@arm.com> wrote:
> >>
> >> On 26/02/2024 08:55, Lance Yang wrote:
> >>> Hey David,
> >>>
> >>> Thanks for your suggestion!
> >>>
> >>> On Mon, Feb 26, 2024 at 4:41 PM David Hildenbrand <david@redhat.com> wrote:
> >>>>
> >>> [...]
> >>>>> On Mon, Feb 26, 2024 at 12:00 PM Barry Song <21cnbao@gmail.com> wrote:
> >>>>> [...]
> >>>>>> On Mon, Feb 26, 2024 at 1:33 AM Lance Yang <ioworker0@gmail.com> wrote:
> >>>>> [...]
> >>> [...]
> >>>>> +static inline bool pte_range_cont_mapped(pte_t *pte, unsigned long nr)
> >>>>> +{
> >>>>> +     pte_t pte_val;
> >>>>> +     unsigned long pfn = pte_pfn(pte);
> >>>>> +     for (int i = 0; i < nr; i++) {
> >>>>> +             pte_val = ptep_get(pte + i);
> >>>>> +             if (pte_none(pte_val) || pte_pfn(pte_val) != (pfn + i))
> >>>>> +                     return false;
> >>>>> +     }
> >>>>> +     return true;
> >>>>> +}
> >>>>
> >>>> I dislike the "cont mapped" terminology.
> >>>>
> >>>> Maybe folio_pte_batch() does what you want?
> >>>
> >>> folio_pte_batch() is a good choice. Appreciate it!
> >>
> >> Agreed, folio_pte_batch() is likely to be widely useful for this change and
> >> others, so suggest exporting it from memory.c and reusing as is if possible.
> >
> > I actually missed folio_pte_batch() in cont-pte series and re-invented
> > a function
> > to check if a large folio is entirely mapped in MADV_PAGEOUT[1]. exporting
> > folio_pte_batch() will also benefit that case. The problem space is same.
> >
> > [1] https://lore.kernel.org/linux-mm/20240118111036.72641-7-21cnbao@gmail.com/
> I am wondering whether we can delay large folio split till page reclaim phase
> for madvise cases.
>
> 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.

>
> Splitting does work here. But it just drops all the benefits of large folio.
>
>
> Regards
> Yin, Fengwei
>
> >
> >>
> >>>
> >>> Best,
> >>> Lance
> >>>
> >>>>
> >>>> --
> >>>> Cheers,
> >>>>
> >>>> David / dhildenb
> >
Thanks
Barry


  reply	other threads:[~2024-02-27  2:17 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-25 12:32 [PATCH 1/1] mm/madvise: enhance lazyfreeing with mTHP in madvise_free 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 [this message]
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
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='CAGsJ_4wx72KOazANBvnGcjdZse8W9+PW5_fspP9=QuX3X_7msg@mail.gmail.com' \
    --to=21cnbao@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=fengwei.yin@intel.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;
as well as URLs for NNTP newsgroup(s).