From: Byungchul Park <byungchul@sk.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
kernel_team@skhynix.com, ying.huang@intel.com, namit@vmware.com,
vernhao@tencent.com, mgorman@techsingularity.net,
hughd@google.com, willy@infradead.org, david@redhat.com,
peterz@infradead.org, luto@kernel.org, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
rjgolo@gmail.com
Subject: Re: [RESEND PATCH v7 6/8] mm: Add APIs to free a folio directly to the buddy bypassing pcp
Date: Tue, 13 Feb 2024 11:03:07 +0900 [thread overview]
Message-ID: <20240213020307.GC4147@system.software.com> (raw)
In-Reply-To: <20240208124919.a0e1707fefc29c2f4213e509@linux-foundation.org>
On Thu, Feb 08, 2024 at 12:49:19PM -0800, Andrew Morton wrote:
> On Thu, 8 Feb 2024 15:26:06 +0900 Byungchul Park <byungchul@sk.com> wrote:
>
> > This is a preparation for migrc mechanism that frees folios at a better
>
> The term "migrc" appears in various places but I don't think we're told
> what is actually means?
>
> > time later, rather than the moment migrating folios. The folios freed by
> > migrc are too old to keep in pcp.
>
> How do we define "too old" and what causes you to believe this is the case?
Migrc defers folio_put() for source folios of migration that would be
unlikely used and frees a bunch of folios at once later. However, it
pollutes pcp, which means fresher folios might get free_pcppages_bulk()ed
and makes the effort to keep the best amount of pcp get unstable. So I
didn't want to make this situation happen.
Byungchul
next prev parent reply other threads:[~2024-02-13 2:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-08 6:26 [RESEND PATCH v7 0/8] Reduce TLB flushes by 94% by improving folio migration Byungchul Park
2024-02-08 6:26 ` [RESEND PATCH v7 1/8] x86/tlb: Add APIs manipulating tlb batch's arch data Byungchul Park
2024-02-08 6:26 ` [RESEND PATCH v7 2/8] arm64: tlbflush: " Byungchul Park
2024-02-08 6:26 ` [RESEND PATCH v7 3/8] mm/rmap: Recognize read-only TLB entries during batched TLB flush Byungchul Park
2024-02-08 6:26 ` [RESEND PATCH v7 4/8] x86/tlb, mm/rmap: Separate arch_tlbbatch_clear() out of arch_tlbbatch_flush() Byungchul Park
2024-02-08 6:26 ` [RESEND PATCH v7 5/8] mm: Separate move/undo doing on folio list from migrate_pages_batch() Byungchul Park
2024-02-08 6:26 ` [RESEND PATCH v7 6/8] mm: Add APIs to free a folio directly to the buddy bypassing pcp Byungchul Park
2024-02-08 20:49 ` Andrew Morton
2024-02-13 2:03 ` Byungchul Park [this message]
2024-02-08 6:26 ` [RESEND PATCH v7 7/8] mm: Defer TLB flush by keeping both src and dst folios at migration Byungchul Park
2024-02-08 20:54 ` Andrew Morton
2024-02-13 1:19 ` Byungchul Park
2024-02-08 6:26 ` [RESEND PATCH v7 8/8] mm: Pause migrc mechanism at high memory pressure Byungchul Park
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=20240213020307.GC4147@system.software.com \
--to=byungchul@sk.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=hughd@google.com \
--cc=kernel_team@skhynix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mgorman@techsingularity.net \
--cc=mingo@redhat.com \
--cc=namit@vmware.com \
--cc=peterz@infradead.org \
--cc=rjgolo@gmail.com \
--cc=tglx@linutronix.de \
--cc=vernhao@tencent.com \
--cc=willy@infradead.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.