linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: "Harry (Hyeonggon) Yoo" <42.hyeyoo@gmail.com>
Cc: Gregory Price <gourry@gourry.net>,
	Honggyu Kim <honggyu.kim@sk.com>,
	Byungchul Park <byungchul@sk.com>,
	kernel_team@skhynix.com, lsf-pc@lists.linux-foundation.org,
	linux-mm@kvack.org, linux-cxl@vger.kernel.org
Subject: Re: [LSF/MM/BPF TOPIC] Restricting or migrating unmovable kernel allocations from slow tier
Date: Mon, 10 Feb 2025 03:19:37 +0000	[thread overview]
Message-ID: <Z6lwSaKmwwFjx5ID@casper.infradead.org> (raw)
In-Reply-To: <Z6lli5cRHh1Ffvql@MacBook-Air-5.local>

On Mon, Feb 10, 2025 at 11:33:47AM +0900, Harry (Hyeonggon) Yoo wrote:
> Premise: Some ZONE_NORMAL capacity exists on CXL memory
>          due to its large capacity.

I reject your premise.  None of this is inevitable.  Infiniband and ATM
did not beocme dominant networking technologies.  SOP did not dominate
the storage industry.  Itanium did not become the only CPU architcture
that mattered.

Similarly, CXL is a technically flawed protocol.  Lots of money is
being thrown at making it look inevitable, but fundamentally PCIe is
a high-bandwidth protocol, not a low-latency protocol and it can't do
the job.

> > There's a reason most kernel allocations are not swappable.
> 
> Because most kernel allocations cannot be swapped, with a few exceptions.
> 
> However, there's non-LRU page migration functionality where kernel
> allocations can be migrated.
> 
> I don't understand why we shouldn't introduce more kernel movable memory
> if that turns out to be beneficial?

Because it's adding complexity for a stupid use-case.

If you can make the case for making something migratable that's not
currently without using CXL as a justification, then sure, let's do it.
zsmalloc is migratable, and that makes a lot of sense.  But there's
a reason we only have three movable_operations structs defined in the
kernel today.

(also the whole non-LRU page migration needs overhauling to not use
page->lru, but that's a separate matter.  except it's not a separate
matter because that's needed in order to shrink struct page.)


  reply	other threads:[~2025-02-10  3:19 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-01 13:29 Hyeonggon Yoo
2025-02-01 14:04 ` Matthew Wilcox
2025-02-01 15:13   ` Hyeonggon Yoo
2025-02-01 16:30     ` Gregory Price
2025-02-01 18:48       ` Matthew Wilcox
2025-02-03 22:09       ` Dan Williams
2025-02-07  7:20   ` Byungchul Park
2025-02-07  8:57     ` Gregory Price
2025-02-07  9:27       ` Gregory Price
2025-02-07  9:34       ` Honggyu Kim
2025-02-07  9:54         ` Gregory Price
2025-02-07 10:49           ` Byungchul Park
2025-02-10  2:33           ` Harry (Hyeonggon) Yoo
2025-02-10  3:19             ` Matthew Wilcox [this message]
2025-02-10  6:00             ` Gregory Price
2025-02-10  7:17               ` Byungchul Park
2025-02-10 15:47                 ` Gregory Price
2025-02-10 15:55                   ` Matthew Wilcox
2025-02-10 16:06                     ` Gregory Price
2025-02-11  1:53                   ` Byungchul Park
2025-02-21  1:52                   ` Harry Yoo
2025-02-25  4:54                     ` [LSF/MM/BPF TOPIC] Gathering ideas to reduce ZONE_NORMAL cost Byungchul Park
2025-02-25  5:06                   ` [LSF/MM/BPF TOPIC] Restricting or migrating unmovable kernel allocations from slow tier Byungchul Park
2025-03-03 15:55                     ` Gregory Price
2025-02-07 10:14       ` Byungchul Park
2025-02-10  7:02       ` Byungchul Park
2025-02-04  9:59 ` David Hildenbrand

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=Z6lwSaKmwwFjx5ID@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=42.hyeyoo@gmail.com \
    --cc=byungchul@sk.com \
    --cc=gourry@gourry.net \
    --cc=honggyu.kim@sk.com \
    --cc=kernel_team@skhynix.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    /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