Hi Greg, Thanks for looking into the patches.
On Thu, Jun 26, 2025 at 12:41:07AM +0530, Shrikanth Hegde wrote:
Add a sysfs file called "avoid" which prints the current CPUs
makred as avoid.
This could be used by userspace components or tools such as irqbalance.
/sys/devices/system/cpu # ca
On 30.06.25 14:59, David Hildenbrand wrote:
Based on mm/mm-new.
In the future, as we decouple "struct page" from "struct folio", pages
that support "non-lru page migration" -- movable_ops page migration
such as memory balloons and zsmalloc -- will no longer be folios. They
will not have ->mappin
On 01.07.25 15:02, Lorenzo Stoakes wrote:
On Mon, Jun 30, 2025 at 03:00:04PM +0200, David Hildenbrand wrote:
We can now simply check for PageAnon() and remove PageMappingFlags().
... and while at it, use the folio instead and operate on
folio->mapping.
Probably worth mentioning to be super cr
On 01.07.25 14:54, Lorenzo Stoakes wrote:
On Mon, Jun 30, 2025 at 03:00:03PM +0200, David Hildenbrand wrote:
KSM is the only remaining user, let's rename the flag. While at it,
adjust to remaining page -> folio in the doc.
Hm I wonder if we could just ideally have this be a separate flag rathe
PAGEFLAG(MovableOps, movable_ops, PF_NO_TAIL);
+/*
+ * A movable_ops page has this flag set while it is isolated for migration.
+ * This flag primarily protects against concurrent migration attempts.
+ *
+ * Once migration ended (success or failure), the flag is cleared. The
+ * flag is manag
On 30 Jun 2025, at 8:59, David Hildenbrand wrote:
> ... and factor the complete handling of movable_ops pages out.
> Convert it similar to isolate_movable_ops_page().
>
> While at it, convert the VM_BUG_ON_FOLIO() into a VM_WARN_ON_PAGE().
>
> Signed-off-by: David Hildenbrand
> ---
> mm/migrate.
Hi!
On Tue, Jul 01, 2025 at 12:49:29PM +0200, Christophe Leroy wrote:
> When building with CONFIG_RELOCATABLE, there is a .interp section
> which contains the name of the expected ELF interpreter:
>
> Contents of section .interp:
> c21c1bac 2f757372 2f6c6962 2f6c642e 736f2e31 /usr/lib/l
On Thu, Jun 26, 2025 at 12:41:07AM +0530, Shrikanth Hegde wrote:
> Add a sysfs file called "avoid" which prints the current CPUs
> makred as avoid.
>
> This could be used by userspace components or tools such as irqbalance.
>
> /sys/devices/system/cpu # cat avoid
> 70-479
You forgot to docum
This series aims to clean up an aspect of coredump generation:
ELF coredumps contain a set of notes describing the state of machine
registers and other information about the dumped process.
Notes are identified by a numeric identifier n_type and a "name"
string, although this terminology is somew
Instead of having the core code guess the note name for each regset,
use USER_REGSET_NOTE_TYPE() to pick the correct name from elf.h.
Signed-off-by: Dave Martin
Cc: Madhavan Srinivasan
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc: Oleg Nesterov
Cc: Kees Cook
Cc: Akihiko
Le 01/07/2025 à 12:15, Heiko Carstens a écrit :
Another thing that needs careful consideration is whether it's
possible to combine kasan_arch_is_ready() and kasan_enabled() into the
same check logically at all. There's one issue mentioned in [1]:
Hello,
I've removed kasan_arch_is_ready() at
On Mon, Jun 30, 2025 at 03:00:07PM +0200, David Hildenbrand wrote:
> Now that the mapping flags are only used for folios, let's rename the
> defines.
>
> Reviewed-by: Zi Yan
> Signed-off-by: David Hildenbrand
As the official King of Churn (TM) I approve of this :)
Reviewed-by: Lorenzo Stoakes
On Tue, Jul 01, 2025 at 12:25:32PM +0200, Christophe Leroy wrote:
> Your patch below is simpler than what I proposed, but it keeps the static
> branches so the overhead remains.
>
> I also proposed a change, it goes further by removing the static branch for
> architectures that don't need it, see
On Mon, Jun 30, 2025 at 03:00:10PM +0200, David Hildenbrand wrote:
> Let's just special-case based on IS_ENABLED(CONFIG_BALLOON_COMPACTION
> like we did for balloon_page_finalize().
>
> Signed-off-by: David Hildenbrand
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> include/linux/balloon_compa
On 01.07.25 13:03, Lorenzo Stoakes wrote:
On Mon, Jun 30, 2025 at 02:59:58PM +0200, David Hildenbrand wrote:
Currently, we only support migration of individual movable_ops pages, so
we can not run into that.
Reviewed-by: Zi Yan
Signed-off-by: David Hildenbrand
Seems sensible, so:
Reviewed-
On Mon, Jun 30, 2025 at 03:00:09PM +0200, David Hildenbrand wrote:
> Let's bring the docs up-to-date. Setting PG_movable_ops + page->private
> very likely still requires to be performed under documented locks:
> it's complicated.
>
> We will rework this in the future, as we will try avoiding using
On Mon, Jun 30, 2025 at 03:00:08PM +0200, David Hildenbrand wrote:
> Let's bring the docs up-to-date.
>
> Reviewed-by: Zi Yan
> Signed-off-by: David Hildenbrand
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> Documentation/mm/page_migration.rst | 39 -
> 1 file cha
On Mon, Jun 30, 2025 at 03:00:06PM +0200, David Hildenbrand wrote:
> Now that PAGE_MAPPING_MOVABLE is gone, we can simplify and rely on the
> folio_test_anon() test only.
>
> ... but staring at the users, this function should never even have been
> called on movable_ops pages. E.g.,
> * __buffer_mi
On Mon, Jun 30, 2025 at 03:00:04PM +0200, David Hildenbrand wrote:
> We can now simply check for PageAnon() and remove PageMappingFlags().
>
> ... and while at it, use the folio instead and operate on
> folio->mapping.
Probably worth mentioning to be super crystal clear that this is because
now it
On Mon, Jun 30, 2025 at 03:00:05PM +0200, David Hildenbrand wrote:
> It's unused and the page counterpart is gone, so let's remove it.
>
> Reviewed-by: Zi Yan
> Signed-off-by: David Hildenbrand
LGTM, so:
Reviewed-by: Lorenzo Stoakes
> ---
> include/linux/page-flags.h | 5 -
> 1 file chan
On Mon, Jun 30, 2025 at 03:00:03PM +0200, David Hildenbrand wrote:
> KSM is the only remaining user, let's rename the flag. While at it,
> adjust to remaining page -> folio in the doc.
Hm I wonder if we could just ideally have this be a separate flag rather than a
bitwise combination, however I be
On Mon, 23 Jun 2025 16:54:20 +0200
"Fabio M. De Francesco" wrote:
> When Firmware First is enabled, BIOS handles errors first and then it makes
> them available to the kernel via the Common Platform Error Record (CPER)
> sections (UEFI 2.10 Appendix N). Linux parses the CPER sections via one of
>
On Mon, 23 Jun 2025 16:54:19 +0200
"Fabio M. De Francesco" wrote:
> I/O Machine Check Architecture events may signal failing PCIe components
> or links. The AER event contains details on what was happening on the wire
> when the error was signaled.
>
> Trace the CPER PCIe Error section (UEFI v2.
On Mon, Jun 30, 2025 at 03:00:02PM +0200, David Hildenbrand wrote:
> Let's rename the flag to make it clearer where it applies (not folios
> ...).
>
> While at it, define the flag only with CONFIG_MIGRATION.
>
> Reviewed-by: Zi Yan
> Signed-off-by: David Hildenbrand
LGTM, so:
Reviewed-by: Loren
On 01.07.25 14:44, Lorenzo Stoakes wrote:
On Mon, Jun 30, 2025 at 03:00:01PM +0200, David Hildenbrand wrote:
Instead, let's use a page flag. As the page flag can result in
false-positives, glue it to the page types for which we
support/implement movable_ops page migration.
The flag reused by Pa
On 01.07.25 14:12, Lorenzo Stoakes wrote:
On Mon, Jun 30, 2025 at 03:00:00PM +0200, David Hildenbrand wrote:
... instead, look them up statically based on the page type. Maybe in the
future we want a registration interface? At least for now, it can be
easily handled using the two page types that
On Mon, Jun 30, 2025 at 03:00:01PM +0200, David Hildenbrand wrote:
> Instead, let's use a page flag. As the page flag can result in
> false-positives, glue it to the page types for which we
> support/implement movable_ops page migration.
>
> The flag reused by PageMovableOps() might be sued by othe
Commit 118c40b7b503 ("kbuild: require gcc-8 and binutils-2.30") raised
minimum GCC_VERSION and LD_VERSION.
Simplify powerpc build accordingly.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig | 2 +-
arch/powerpc/boot/wrapper | 6 +-
2 files changed, 2 insertions(+), 6 deletion
---
include/linux/page-flags.h | 6 --
mm/migrate.c | 43 --
mm/vmscan.c| 6 --
3 files changed, 17 insertions(+), 38 deletions(-)
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index c67163b73c
OK I guess this is fine... :)
An aside, unrelated tot his series: it'd be nice to use 'deflate' consistently
in this code. We do __count_vm_event(BALLOON_DEFLATE) in
balloon_page_list_dequeue() but say 'deflate' nowhere else... well before this
patch :)
Right, dequeue is actually deflate, becau
On 01.07.25 12:59, Lorenzo Stoakes wrote:
On Mon, Jun 30, 2025 at 02:59:57PM +0200, David Hildenbrand wrote:
Let's make it clearer that we are talking about movable_ops pages.
While at it, convert a VM_BUG_ON to a VM_WARN_ON_ONCE_PAGE.
<3
Reviewed-by: Zi Yan
Signed-off-by: David Hildenbra
On 01.07.25 12:50, Lorenzo Stoakes wrote:
On Mon, Jun 30, 2025 at 02:59:56PM +0200, David Hildenbrand wrote:
As __ClearPageMovable() is gone that would have only made
PageMovable()==false but still __PageMovable()==true, now
PageMovable() == __PageMovable().
I think this could be rephrased to
On 01.07.25 12:43, Lorenzo Stoakes wrote:
On Mon, Jun 30, 2025 at 02:59:55PM +0200, David Hildenbrand wrote:
Unused, let's remove it.
The Chinese docs in Documentation/translations/zh_CN/mm/page_migration.rst
still mention it, but that whole docs is destined to get outdated and
updated by someb
When building with CONFIG_RELOCATABLE, there is a .interp section
which contains the name of the expected ELF interpreter:
Contents of section .interp:
c21c1bac 2f757372 2f6c6962 2f6c642e 736f2e31 /usr/lib/ld.so.1
c21c1bbc 00 .
That information
On Mon, Jun 30, 2025 at 03:00:00PM +0200, David Hildenbrand wrote:
> ... instead, look them up statically based on the page type. Maybe in the
> future we want a registration interface? At least for now, it can be
> easily handled using the two page types that actually support page
> migration.
>
>
On Mon, Jun 30, 2025 at 02:59:59PM +0200, David Hildenbrand wrote:
> Convert to page_has_movable_ops(). While at it, cleanup relevant code
> a bit.
>
> The data_race() in migrate_folio_unmap() is questionable: we already
> hold a page reference, and concurrent modifications can no longer
> happen (
On Tue, Jul 01, 2025 at 12:19:47PM +0200, David Hildenbrand wrote:
> On 01.07.25 12:03, Lorenzo Stoakes wrote:
> > On Mon, Jun 30, 2025 at 02:59:54PM +0200, David Hildenbrand wrote:
> > > We can just look at the balloon device (stored in page->private), to see
> > > if the page is still part of the
On Tue, Jul 01, 2025 at 12:15:41PM +0200, David Hildenbrand wrote:
> On 30.06.25 19:07, Lorenzo Stoakes wrote:
> > On Mon, Jun 30, 2025 at 02:59:51PM +0200, David Hildenbrand wrote:
> > > Folios will have nothing to do with movable_ops page migration. These
> > > functions are now unused, so let's
On Mon, Jun 30, 2025 at 02:59:58PM +0200, David Hildenbrand wrote:
> Currently, we only support migration of individual movable_ops pages, so
> we can not run into that.
>
> Reviewed-by: Zi Yan
> Signed-off-by: David Hildenbrand
Seems sensible, so:
Reviewed-by: Lorenzo Stoakes
Maybe worth add
On Mon, Jun 30, 2025 at 02:59:57PM +0200, David Hildenbrand wrote:
> Let's make it clearer that we are talking about movable_ops pages.
>
> While at it, convert a VM_BUG_ON to a VM_WARN_ON_ONCE_PAGE.
<3
>
> Reviewed-by: Zi Yan
> Signed-off-by: David Hildenbrand
Great, love it.
Reviewed-by: Lo
On 01.07.25 10:27, Lorenzo Stoakes wrote:
On Tue, Jul 01, 2025 at 10:17:13AM +0200, David Hildenbrand wrote:
On 30.06.25 17:27, Lorenzo Stoakes wrote:
On Mon, Jun 30, 2025 at 02:59:45PM +0200, David Hildenbrand wrote:
Currently, any user of page types must clear that type before freeing
a page
On Mon, Jun 30, 2025 at 02:59:56PM +0200, David Hildenbrand wrote:
> As __ClearPageMovable() is gone that would have only made
> PageMovable()==false but still __PageMovable()==true, now
> PageMovable() == __PageMovable().
I think this could be rephrased to be clearer, something like:
Pre
On Mon, Jun 30, 2025 at 02:59:55PM +0200, David Hildenbrand wrote:
> Unused, let's remove it.
>
> The Chinese docs in Documentation/translations/zh_CN/mm/page_migration.rst
> still mention it, but that whole docs is destined to get outdated and
> updated by somebody that actually speaks that langua
On Mon, Jun 30, 2025 at 02:59:53PM +0200, David Hildenbrand wrote:
> Instead, let's check in the callbacks if the page was already destroyed,
> which can be checked by looking at zpdesc->zspage (see reset_zpdesc()).
>
> If we detect that the page was destroyed:
>
> (1) Fail isolation, just like the
On 01.07.25 12:03, Lorenzo Stoakes wrote:
On Mon, Jun 30, 2025 at 02:59:54PM +0200, David Hildenbrand wrote:
We can just look at the balloon device (stored in page->private), to see
if the page is still part of the balloon.
As isolated balloon pages cannot get released (they are taken off the
b
> > > Another thing that needs careful consideration is whether it's
> > > possible to combine kasan_arch_is_ready() and kasan_enabled() into the
> > > same check logically at all. There's one issue mentioned in [1]:
> >
> > Hello,
> > I've removed kasan_arch_is_ready() at all in this series:
> > [
On 30.06.25 19:07, Lorenzo Stoakes wrote:
On Mon, Jun 30, 2025 at 02:59:51PM +0200, David Hildenbrand wrote:
Folios will have nothing to do with movable_ops page migration. These
functions are now unused, so let's remove them.
Maybe worth mentioning that __folio_test_movable() is still a thing
On 01.07.25 11:24, David Hildenbrand wrote:
On 30.06.25 19:05, Lorenzo Stoakes wrote:
On Mon, Jun 30, 2025 at 02:59:50PM +0200, David Hildenbrand wrote:
Let's factor it out, simplifying the calling code.
The assumption is that flush_dcache_page() is not required for
movable_ops pages: as docum
On Mon, Jun 30, 2025 at 02:59:54PM +0200, David Hildenbrand wrote:
> We can just look at the balloon device (stored in page->private), to see
> if the page is still part of the balloon.
>
> As isolated balloon pages cannot get released (they are taken off the
> balloon list while isolated), we don'
On 01.07.25 10:37, Lorenzo Stoakes wrote:
On Tue, Jul 01, 2025 at 10:34:33AM +0200, David Hildenbrand wrote:
Reviewed-by: Zi Yan
Acked-by: Harry Yoo
Signed-off-by: David Hildenbrand
Based on discussion below, I'm good with this now with the comment change, so
feel free to add:
Reviewed-by:
[...]
-{
- __ClearPageOffline(page);
- __ClearPageMovable(page);
- set_page_private(page, 0);
- /*
-* No touch page.lru field once @page has been isolated
-* because VM is using the field.
-*/
- if (!PageIsolated(page))
- list_d
On Mon, Jun 30, 2025 at 02:59:52PM +0200, David Hildenbrand wrote:
> Let's move that handling directly into migrate_folio_move(), so we can
> simplify move_to_new_folio(). While at it, fixup the documentation a
> bit.
>
> Note that unmap_and_move_huge_page() does not care, because it only
> deals w
On 30.06.25 19:05, Lorenzo Stoakes wrote:
On Mon, Jun 30, 2025 at 02:59:50PM +0200, David Hildenbrand wrote:
Let's factor it out, simplifying the calling code.
The assumption is that flush_dcache_page() is not required for
movable_ops pages: as documented for flush_dcache_folio(), it really
onl
15.1.0
archsdk_defconfiggcc-15.1.0
arc randconfig-001-20250630gcc-10.5.0
arc randconfig-001-20250701gcc-13.3.0
arc randconfig-002-20250630gcc-12.4.0
arc randconfig-002-20250701gcc-
On Tue, Jul 01, 2025 at 10:29:54AM +0200, David Hildenbrand wrote:
> > I wonder, in the wonderful future where PageXXX() always refers to a page,
> > can
> > we use something less horrible than these macros?
>
> Good question. It all interacts with how we believe compound pages will work
> / look
On Tue, Jul 01, 2025 at 10:17:13AM +0200, David Hildenbrand wrote:
> On 30.06.25 17:27, Lorenzo Stoakes wrote:
> > On Mon, Jun 30, 2025 at 02:59:45PM +0200, David Hildenbrand wrote:
> > > Currently, any user of page types must clear that type before freeing
> > > a page back to the buddy, otherwise
On Tue, Jul 01, 2025 at 09:58:09AM +0200, David Hildenbrand wrote:
> On 30.06.25 17:15, Lorenzo Stoakes wrote:
> > On Mon, Jun 30, 2025 at 02:59:43PM +0200, David Hildenbrand wrote:
> > > Let's move the removal of the page from the balloon list into the single
> > > caller, to remove the dependency
On Tue, Jul 01, 2025 at 10:03:57AM +0200, David Hildenbrand wrote:
> > > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> > > index 999b513c7fdff..7f1431f2be98f 100644
> > > --- a/mm/zsmalloc.c
> > > +++ b/mm/zsmalloc.c
> > > @@ -1719,8 +1719,6 @@ static bool zs_page_isolate(struct page *page,
> > > i
On Tue, Jul 01, 2025 at 10:34:33AM +0200, David Hildenbrand wrote:
> > > > > Reviewed-by: Zi Yan
> > > > > Acked-by: Harry Yoo
> > > > > Signed-off-by: David Hildenbrand
Based on discussion below, I'm good with this now with the comment change, so
feel free to add:
Reviewed-by: Lorenzo Stoakes
On Mon, Jun 30, 2025 at 02:59:55PM +0200, David Hildenbrand wrote:
> Unused, let's remove it.
>
> The Chinese docs in Documentation/translations/zh_CN/mm/page_migration.rst
> still mention it, but that whole docs is destined to get outdated and
> updated by somebody that actually speaks that langu
On 30.06.25 18:24, Lorenzo Stoakes wrote:
On Mon, Jun 30, 2025 at 02:59:48PM +0200, David Hildenbrand wrote:
... and start moving back to per-page things that will absolutely not be
folio things in the future. Add documentation and a comment that the
remaining folio stuff (lock, refcount) will h
On 30.06.25 18:03, Lorenzo Stoakes wrote:
On Mon, Jun 30, 2025 at 02:59:47PM +0200, David Hildenbrand wrote:
Let the page freeing code handle clearing the page type.
Acked-by: Zi Yan
Reviewed-by: Sergey Senozhatsky
Acked-by: Harry Yoo
Signed-off-by: David Hildenbrand
On basis of sanity of
On Mon, Jun 30, 2025 at 02:59:53PM +0200, David Hildenbrand wrote:
> Instead, let's check in the callbacks if the page was already destroyed,
> which can be checked by looking at zpdesc->zspage (see reset_zpdesc()).
>
> If we detect that the page was destroyed:
>
> (1) Fail isolation, just like t
On 30.06.25 18:01, Lorenzo Stoakes wrote:
On Mon, Jun 30, 2025 at 02:59:46PM +0200, David Hildenbrand wrote:
Let the page freeing code handle clearing the page type.
Why is this advantageous? We want to keep the page marked offline for longer?
Less code? ;)
I will add:
"Being able to ident
On 30.06.25 17:27, Lorenzo Stoakes wrote:
On Mon, Jun 30, 2025 at 02:59:45PM +0200, David Hildenbrand wrote:
Currently, any user of page types must clear that type before freeing
a page back to the buddy, otherwise we'll run into mapcount related
sanity checks (because the page type currently ov
On 30.06.25 18:14, Zi Yan wrote:
On 30 Jun 2025, at 12:01, Lorenzo Stoakes wrote:
On Mon, Jun 30, 2025 at 02:59:46PM +0200, David Hildenbrand wrote:
Let the page freeing code handle clearing the page type.
Why is this advantageous? We want to keep the page marked offline for longer?
Acked
On 01.07.25 08:13, Harry Yoo wrote:
On Mon, Jun 30, 2025 at 12:14:01PM -0400, Zi Yan wrote:
On 30 Jun 2025, at 12:01, Lorenzo Stoakes wrote:
On Mon, Jun 30, 2025 at 02:59:46PM +0200, David Hildenbrand wrote:
Let the page freeing code handle clearing the page type.
Why is this advantageous?
On 30.06.25 17:17, Lorenzo Stoakes wrote:
On Mon, Jun 30, 2025 at 02:59:44PM +0200, David Hildenbrand wrote:
Let's drop these checks; these are conditions the core migration code
must make sure will hold either way, no need to double check.
Acked-by: Zi Yan
Reviewed-by: Sergey Senozhatsky
Ack
On 30.06.25 17:15, Lorenzo Stoakes wrote:
On Mon, Jun 30, 2025 at 02:59:43PM +0200, David Hildenbrand wrote:
Let's move the removal of the page from the balloon list into the single
caller, to remove the dependency on the PG_isolated flag and clarify
locking requirements.
We'll shuffle the oper
On Mon, Jun 30, 2025 at 02:59:52PM +0200, David Hildenbrand wrote:
> Let's move that handling directly into migrate_folio_move(), so we can
> simplify move_to_new_folio(). While at it, fixup the documentation a
> bit.
>
> Note that unmap_and_move_huge_page() does not care, because it only
> deals
On Mon, Jun 30, 2025 at 02:59:50PM +0200, David Hildenbrand wrote:
> Let's factor it out, simplifying the calling code.
>
> The assumption is that flush_dcache_page() is not required for
> movable_ops pages: as documented for flush_dcache_folio(), it really
> only applies when the kernel wrote to
71 matches
Mail list logo
