Message ID | 20231215071604.946a433bbc05a6409faf5a33@linux-foundation.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-1197-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:3b04:b0:fb:cd0c:d3e with SMTP id c4csp9351466dys; Fri, 15 Dec 2023 07:18:40 -0800 (PST) X-Google-Smtp-Source: AGHT+IGetfuYs0c9N2RtkcHAnWEQ9cuxXFBeZ56Pyghp2kanNpEJxw3fH7l+JKaVix2IP4ZkU6H/ X-Received: by 2002:a05:6358:248e:b0:16d:bd0e:fddb with SMTP id m14-20020a056358248e00b0016dbd0efddbmr4230810rwc.15.1702653520117; Fri, 15 Dec 2023 07:18:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702653520; cv=none; d=google.com; s=arc-20160816; b=XZk4bi2zijd/61+QPLe85GnzwJ4xHBl08u5GeuqVmfqoict9pGJqz1zEJ+ZwEio9Sm LHxOvncX/xlHECTTdAUSugJAnC3tSlpEJClibIAkFevO6XxsJLNK6SVCyAkgT+qJNy9J A1w73AV+5dunyeDef35EcHCqPYxavJtSoESl1zbW4f/z/yK0IQncMq1ud9vOySWP+uWT JKfsNZaVUGYxNefZsw3+NrbRh4ikf84PPI7+L1tN2Diwarz/32hwyMam6cyCqhE67Wv+ mNOxagBEs26x0yLY/HE4r09D4OgPb3hizAGHnkRXSX1qTGcNcC2HaXiGPVQ1cEkR8/WQ L7bA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:subject:cc:to:from :date:dkim-signature; bh=juu9JWTGTCldH+/X1OLUGs6Nb9laM8gRWhktPzIePxE=; fh=cB2qzcCQjiKdJyGieofKCaYg6v/1hfx5Vh2NqbIiskc=; b=KHUWP4HCBRLx1SsH1KVSSHgBXVHq+9/AWvNObEeKntTgEQtT8oqIPSTPvaTWHwV89p Lhi09YwKty93LXYyQ4RsA4QcJEDVI/aE/RrQQVh7T4egUwsgRMkTD4IRmtvVBwl9KxV7 CIGwZ9htbawPqveEEy9Z8wSLorWrV8xkOo512tianMFUiD/L6SavuWzkz7alBEXUrlaP Py7948+8uhc2tWoHrDif+K0Z1dlLIA2tyqE588SyfLTp60qUSegI02746plnw6+7aR6d lG0qohVT8WLNas0JqWxWlc9JED/bYpIT9EbSDjN0EESw8z29I9aTE6S6FjRYymPAZgdx bWEw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=fyOrI+jF; spf=pass (google.com: domain of linux-kernel+bounces-1197-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-1197-ouuuleilei=gmail.com@vger.kernel.org" Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id b4-20020a0ce884000000b0067a084c38f3si5277551qvo.205.2023.12.15.07.18.40 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Dec 2023 07:18:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-1197-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=fyOrI+jF; spf=pass (google.com: domain of linux-kernel+bounces-1197-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-1197-ouuuleilei=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id E13AB1C237B2 for <ouuuleilei@gmail.com>; Fri, 15 Dec 2023 15:18:39 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D1C443A8CF; Fri, 15 Dec 2023 15:16:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="fyOrI+jF" X-Original-To: linux-kernel@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D145539FD5; Fri, 15 Dec 2023 15:16:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 41176C433C7; Fri, 15 Dec 2023 15:16:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1702653365; bh=EfTyLi3GnxThzOpoGpPm9B/IL1186AUJ8lO3cfsOnEs=; h=Date:From:To:Cc:Subject:From; b=fyOrI+jFtCm8Si8oCHa9W0O8JWCi/njd1/bNEjqBluNUYV/12dwFlf6t6WcLC2yVa +owKpATub/G0QIYm67VEfU2qmwITh88A6vaY/4fMZN5ZBDieouml1AqE0xUc2e1JnD yF5hYSrRl9JzyhBVwN0lOksKmlPPWfKVNCvf9DKM= Date: Fri, 15 Dec 2023 07:16:04 -0800 From: Andrew Morton <akpm@linux-foundation.org> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: linux-mm@kvack.org, mm-commits@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [GIT PULL] hotfixes for 6.7-rc6 Message-Id: <20231215071604.946a433bbc05a6409faf5a33@linux-foundation.org> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785361617296687858 X-GMAIL-MSGID: 1785361617296687858 |
Series |
[GIT,PULL] hotfixes for 6.7-rc6
|
|
Pull-request
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm tags/mm-hotfixes-stable-2023-12-15-07-11Message
Andrew Morton
Dec. 15, 2023, 3:16 p.m. UTC
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(-)
Comments
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?