Linus, please merge this batch of MM, kexec and selftests hotfixes, thanks.
The following changes since commit 0c92218f4e7d4b4a7245d32bea042fa6f9cc39d7:
Merge branch 'master' into mm-hotfixes-stable (2023-12-06 17:03:50 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm tags/mm-hotfixes-stable-2023-12-15-07-11
for you to fetch changes up to 4376807bf2d5371c3e00080c972be568c3f8a7d1:
mm/mglru: reclaim offlined memcgs harder (2023-12-12 17:20:20 -0800)
----------------------------------------------------------------
17 hotfixes. 8 are cc:stable and the other 9 pertain to post-6.6 issues.
----------------------------------------------------------------
Baoquan He (6):
riscv: fix VMALLOC_START definition
loongarch, kexec: change dependency of object files
m68k, kexec: fix the incorrect ifdeffery and build dependency of CONFIG_KEXEC
mips, kexec: fix the incorrect ifdeffery and dependency of CONFIG_KEXEC
sh, kexec: fix the incorrect ifdeffery and dependency of CONFIG_KEXEC
x86, kexec: fix the wrong ifdeffery CONFIG_KEXEC
David Hildenbrand (1):
selftests/mm: cow: print ksft header before printing anything else
David Stevens (1):
mm/shmem: fix race in shmem_undo_range w/THP
Ignat Korchagin (1):
kexec: drop dependency on ARCH_SUPPORTS_KEXEC from CRASH_DUMP
John Hubbard (1):
Revert "selftests: error out if kernel header files are not yet built"
Kefeng Wang (1):
mm: fix VMA heap bounds checking
SeongJae Park (1):
mm/damon/core: make damon_start() waits until kdamond_fn() starts
Yu Zhao (4):
mm/mglru: fix underprotected page cache
mm/mglru: try to stop at high watermarks
mm/mglru: respect min_ttl_ms with memcgs
mm/mglru: reclaim offlined memcgs harder
Yuntao Wang (1):
crash_core: fix the check for whether crashkernel is from high memory
arch/loongarch/kernel/Makefile | 2 +-
arch/m68k/include/asm/kexec.h | 4 +-
arch/m68k/kernel/Makefile | 2 +-
arch/mips/cavium-octeon/smp.c | 4 +-
arch/mips/include/asm/kexec.h | 2 +-
arch/mips/include/asm/smp-ops.h | 2 +-
arch/mips/include/asm/smp.h | 2 +-
arch/mips/kernel/Makefile | 2 +-
arch/mips/kernel/smp-bmips.c | 4 +-
arch/mips/kernel/smp-cps.c | 10 ++---
arch/mips/loongson64/reset.c | 4 +-
arch/mips/loongson64/smp.c | 2 +-
arch/riscv/Kconfig | 4 +-
arch/riscv/include/asm/pgtable.h | 2 +-
arch/riscv/kernel/crash_core.c | 4 +-
arch/sh/include/asm/kexec.h | 4 +-
arch/sh/kernel/Makefile | 2 +-
arch/sh/kernel/reboot.c | 4 +-
arch/sh/kernel/setup.c | 2 +-
arch/x86/boot/compressed/acpi.c | 2 +-
include/linux/damon.h | 2 +
include/linux/mm.h | 8 ++--
include/linux/mm_inline.h | 23 ++++++----
include/linux/mmzone.h | 34 ++++++++-------
kernel/Kconfig.kexec | 1 -
kernel/crash_core.c | 10 ++---
mm/damon/core.c | 6 +++
mm/shmem.c | 19 ++++++++-
mm/vmscan.c | 92 ++++++++++++++++++++++++++--------------
mm/workingset.c | 6 +--
tools/testing/selftests/Makefile | 21 +--------
tools/testing/selftests/lib.mk | 40 ++---------------
tools/testing/selftests/mm/cow.c | 3 +-
33 files changed, 171 insertions(+), 158 deletions(-)
The pull request you sent on Fri, 15 Dec 2023 07:16:04 -0800:
> git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm tags/mm-hotfixes-stable-2023-12-15-07-11
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a62aa88ba1a386e9b6953083b1ceb2fe027238b9
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
On Fri, 15 Dec 2023 at 07:16, Andrew Morton <[email protected]> wrote:
>
> Yu Zhao (4):
> mm/mglru: fix underprotected page cache
> mm/mglru: try to stop at high watermarks
> mm/mglru: respect min_ttl_ms with memcgs
> mm/mglru: reclaim offlined memcgs harder
Entirely unrelated to this pull request (which I already pulled and
pushed out, as noted by pr-tracker-bot), since I looked at these it
just reminded me about a question I've had for a while...
Do we have any long-term (or even short-term?) plans to just make
mglru be the one and only model?
Yes, right now it's not just a Kconfig choice, but a real technical
issue too: it depends on having enough flags available, so we have
that "cannot use it on 32-bit with sparsemem".
But I'm hoping there is a plan or a workaround for that?
Because I feel like we really don't want to keep this "two different
models" situation around forever.
Linus
On Fri, 15 Dec 2023 12:11:42 -0800 Linus Torvalds <[email protected]> wrote:
> On Fri, 15 Dec 2023 at 07:16, Andrew Morton <[email protected]> wrote:
> >
> > Yu Zhao (4):
> > mm/mglru: fix underprotected page cache
> > mm/mglru: try to stop at high watermarks
> > mm/mglru: respect min_ttl_ms with memcgs
> > mm/mglru: reclaim offlined memcgs harder
>
> Entirely unrelated to this pull request (which I already pulled and
> pushed out, as noted by pr-tracker-bot), since I looked at these it
> just reminded me about a question I've had for a while...
>
> Do we have any long-term (or even short-term?) plans to just make
> mglru be the one and only model?
I hope so, but I haven't heard specific plans.
Things are still stabilizing, but it seems we're a fair way down that
exponential curve.
> Yes, right now it's not just a Kconfig choice, but a real technical
> issue too: it depends on having enough flags available, so we have
> that "cannot use it on 32-bit with sparsemem".
>
> But I'm hoping there is a plan or a workaround for that?
Hopefully Yu can talk to that.
> Because I feel like we really don't want to keep this "two different
> models" situation around forever.
>
Sure. Some diehards are still using slab :(
On Fri, Dec 15, 2023 at 1:22 PM Andrew Morton <[email protected]> wrote:
>
> On Fri, 15 Dec 2023 12:11:42 -0800 Linus Torvalds <[email protected]> wrote:
>
> > On Fri, 15 Dec 2023 at 07:16, Andrew Morton <[email protected]> wrote:
> > >
> > > Yu Zhao (4):
> > > mm/mglru: fix underprotected page cache
> > > mm/mglru: try to stop at high watermarks
> > > mm/mglru: respect min_ttl_ms with memcgs
> > > mm/mglru: reclaim offlined memcgs harder
> >
> > Entirely unrelated to this pull request (which I already pulled and
> > pushed out, as noted by pr-tracker-bot), since I looked at these it
> > just reminded me about a question I've had for a while...
> >
> > Do we have any long-term (or even short-term?) plans to just make
> > mglru be the one and only model?
>
> I hope so, but I haven't heard specific plans.
I don't know when we'll get there, if we can get there at all. But we
have been steadily moving toward that goal:
1. We worked with all major distros that follow the mainline closely
to switch to MGLRU this summer (Arch, Debian, Fedora, Gentoo and
Ubuntu).
2. We hired more kernel developers after we demonstrated the ability
to substantially lower hardware cost by overcommitting memory at
scale.
There has been a short-term plan, i.e., moving some of folio->flags to
the lower bits of folio->lru so that we can drop the Kconfig
constraint. I have discussed this with Willy but never acted on it. My
priority has been to surface more of our ideas that can potentially
save users money on memory to the community. I'm CC'ing our team
leads. Please feel free to let us know your preference on the
priority. Thanks.
On Fri, 15 Dec 2023 at 20:57, Yu Zhao <[email protected]> wrote:
>
> There has been a short-term plan, i.e., moving some of folio->flags to
> the lower bits of folio->lru so that we can drop the Kconfig
> constraint. I have discussed this with Willy but never acted on it. My
> priority has been to surface more of our ideas that can potentially
> save users money on memory to the community. I'm CC'ing our team
> leads. Please feel free to let us know your preference on the
> priority.
This is definitely a "eventually" thing on my wishlist, so I was more
just wanting to hear that there is a plan, and somebody working on
it..
Thanks,
Linus
On Sat, Dec 16, 2023 at 04:16:45PM -0800, Linus Torvalds wrote:
> On Fri, 15 Dec 2023 at 20:57, Yu Zhao <[email protected]> wrote:
> >
> > There has been a short-term plan, i.e., moving some of folio->flags to
> > the lower bits of folio->lru so that we can drop the Kconfig
> > constraint. I have discussed this with Willy but never acted on it. My
> > priority has been to surface more of our ideas that can potentially
> > save users money on memory to the community. I'm CC'ing our team
> > leads. Please feel free to let us know your preference on the
> > priority.
>
> This is definitely a "eventually" thing on my wishlist, so I was more
> just wanting to hear that there is a plan, and somebody working on
> it..
"eventually" we should get rid of LRUs altogether. They're no good for
a modern CPU.
https://lore.kernel.org/linux-mm/[email protected]/
I don't have much more in the way of thoughts on what this might look
like beyond that email. I'm inclined towards something incredibly simple
like taking each 4MB chunk of memory in turn; freeing inactive pages
and marking active pages as inactive.
On Sun, 17 Dec 2023 15:40:19 +0000 Matthew Wilcox <[email protected]> wrote:
> On Sat, Dec 16, 2023 at 04:16:45PM -0800, Linus Torvalds wrote:
> > On Fri, 15 Dec 2023 at 20:57, Yu Zhao <[email protected]> wrote:
> > >
> > > There has been a short-term plan, i.e., moving some of folio->flags to
> > > the lower bits of folio->lru so that we can drop the Kconfig
> > > constraint. I have discussed this with Willy but never acted on it. My
> > > priority has been to surface more of our ideas that can potentially
> > > save users money on memory to the community. I'm CC'ing our team
> > > leads. Please feel free to let us know your preference on the
> > > priority.
> >
> > This is definitely a "eventually" thing on my wishlist, so I was more
> > just wanting to hear that there is a plan, and somebody working on
> > it..
>
> "eventually" we should get rid of LRUs altogether. They're no good for
> a modern CPU.
>
> https://lore.kernel.org/linux-mm/[email protected]/
>
OK, but...
What of the cost of physical I/O? If a computationally more expensive
scan results in less I/O (hopefully) then the balance is altered?