| Message ID | 20231215071604.946a433bbc05a6409faf5a33@linux-foundation.org (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [GIT,PULL] hotfixes for 6.7-rc6 | expand |
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!
On Fri, 15 Dec 2023 at 07:16, Andrew Morton <akpm@linux-foundation.org> 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 <torvalds@linux-foundation.org> wrote: > On Fri, 15 Dec 2023 at 07:16, Andrew Morton <akpm@linux-foundation.org> 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 <akpm@linux-foundation.org> wrote: > > On Fri, 15 Dec 2023 12:11:42 -0800 Linus Torvalds <torvalds@linux-foundation.org> wrote: > > > On Fri, 15 Dec 2023 at 07:16, Andrew Morton <akpm@linux-foundation.org> 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 <yuzhao@google.com> 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 <yuzhao@google.com> 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/ZTc7SHQ4RbPkD3eZ@casper.infradead.org/ 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 <willy@infradead.org> wrote: > On Sat, Dec 16, 2023 at 04:16:45PM -0800, Linus Torvalds wrote: > > On Fri, 15 Dec 2023 at 20:57, Yu Zhao <yuzhao@google.com> 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/ZTc7SHQ4RbPkD3eZ@casper.infradead.org/ > 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?
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(-)