From: "Huang, Ying" <ying.huang@intel.com>
To: Barry Song <21cnbao@gmail.com>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>,
David Hildenbrand <david@redhat.com>,
akpm@linux-foundation.org, willy@infradead.org,
ryan.roberts@arm.com, ziy@nvidia.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: drop the 'anon_' prefix for swap-out mTHP counters
Date: Thu, 23 May 2024 09:14:10 +0800 [thread overview]
Message-ID: <875xv5ba8t.fsf@yhuang6-desk2.ccr.corp.intel.com> (raw)
In-Reply-To: <CAGsJ_4zSuOTPi+zkS_kvS5T0MsdMBR+2gpXukJt0aMPrEnCDZg@mail.gmail.com> (Barry Song's message of "Wed, 22 May 2024 22:40:20 +1200")
Barry Song <21cnbao@gmail.com> writes:
> On Wed, May 22, 2024 at 9:38 PM Baolin Wang
> <baolin.wang@linux.alibaba.com> wrote:
>>
>>
>>
>> On 2024/5/22 16:58, David Hildenbrand wrote:
>> > On 22.05.24 10:51, Baolin Wang wrote:
>> >> The mTHP swap related counters: 'anon_swpout' and
>> >> 'anon_swpout_fallback' are
>> >> confusing with an 'anon_' prefix, since the shmem can swap out
>> >> non-anonymous
>> >> pages. So drop the 'anon_' prefix to keep consistent with the old swap
>> >> counter
>> >> names.
>> >>
>> >> Suggested-by: "Huang, Ying" <ying.huang@intel.com>
>> >> Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
>> >> ---
>> >
>> > Am I daydreaming or did we add the anon_ for a reason and discussed the
>> > interaction with shmem? At least I remember some discussion around that.
>>
>> Do you mean the shmem mTHP allocation counters in previous
>> discussion[1]? But for 'anon_swpout' and 'anon_swpout_fallback', I can
>> not find previous discussions that provided a reason for adding the
>> ‘anon_’ prefix. Barry, any comments? Thanks.
>
> HI Baolin,
> We had tons of emails discussing about namin and I found this email,
>
> https://lore.kernel.org/all/bca6d142-15fd-4af5-9f71-821f891e8305@redhat.com/
>
> David had this comment,
> "I'm wondering if these should be ANON specific for now. We might want to
> add others (shmem, file) in the future."
>
> This is likely how the 'anon_' prefix started being added, although it
> wasn't specifically
> targeting swapout.
>
> I sense your patch slightly alters the behavior of thp_swpout_fallback
> in /proc/vmstat.
> Previously, we didn't classify them as THP_SWPOUT_FALLBACK, even though we
> always split them.
IIUC, "fallback" means you try to do something, but fail, so try
something else as fallback. If so, then we don't need to count
splitting shmem large folio as fallback.
For example, before commit 5ed890ce5147 ("mm: vmscan: avoid split during
shrink_folio_list()"), if folio_entire_mapcount() == 0, we will split
the THP. But we will not count it as "fallback" because we haven't
tried to swap it out as a whole.
>
> if (folio_test_anon(folio) && folio_test_swapbacked(folio)) {
> ...
> if (!add_to_swap(folio)) {
> int __maybe_unused order =
> folio_order(folio);
>
> if (!folio_test_large(folio))
> goto activate_locked_split;
> /* Fallback to swap normal pages */
> if (split_folio_to_list(folio,
> folio_list))
> goto activate_locked;
> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> if (nr_pages >= HPAGE_PMD_NR) {
> count_memcg_folio_events(folio,
> THP_SWPOUT_FALLBACK, 1);
>
> count_vm_event(THP_SWPOUT_FALLBACK);
> }
> count_mthp_stat(order,
> MTHP_STAT_ANON_SWPOUT_FALLBACK);
> #endif
> if (!add_to_swap(folio))
> goto activate_locked_split;
> }
> }
> } else if (folio_test_swapbacked(folio) &&
> folio_test_large(folio)) {
> /* Split shmem folio */
> if (split_folio_to_list(folio, folio_list))
> goto keep_locked;
> }
>
>
>
> If the goal is to incorporate pmd-mapped shmem under thp_swpout* in
> /proc/vmstat,
> and if there is consistency between /proc/vmstat and sys regarding
> their definitions,
> then I have no objection to this patch. However, shmem_swpout and shmem_swpout_*
> appear more intuitive, given that thp_swpout_* in /proc/vmstat has
> never shown any
> increments for shmem until now - we have been always splitting shmem in vmscan.
>
> By the way, if this patch is accepted, it must be included in version
> 6.10 to maintain
> ABI compatibility. Additionally, documentation must be updated accordingly.
>
>>
>> [1]
>> https://lore.kernel.org/all/05d0096e4ec3e572d1d52d33a31a661321ac1551.1713755580.git.baolin.wang@linux.alibaba.com/
>
--
Best Regards,
Huang, Ying
next prev parent reply other threads:[~2024-05-23 1:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-22 8:51 Baolin Wang
[not found] ` <22ac01a3-ddbb-4114-88cd-ad1a31982dad@redhat.com>
2024-05-22 9:38 ` Baolin Wang
2024-05-22 10:40 ` Barry Song
2024-05-22 11:24 ` Baolin Wang
2024-05-22 12:11 ` Lance Yang
2024-05-23 1:02 ` Huang, Ying
2024-05-23 1:14 ` Huang, Ying [this message]
2024-05-23 1:37 ` Baolin Wang
2024-05-23 2:12 ` Barry Song
2024-05-23 2:31 ` Baolin Wang
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=875xv5ba8t.fsf@yhuang6-desk2.ccr.corp.intel.com \
--to=ying.huang@intel.com \
--cc=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ryan.roberts@arm.com \
--cc=willy@infradead.org \
--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