From: Matthew Wilcox <willy@infradead.org>
To: Hugh Dickins <hughd@google.com>
Cc: "Vishal Moola (Oracle)" <vishal.moola@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-arch@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org,
linux-hexagon@vger.kernel.org, loongarch@lists.linux.dev,
linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
linux-openrisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
linux-um@lists.infradead.org, xen-devel@lists.xenproject.org,
kvm@vger.kernel.org, Catalin Marinas <catalin.marinas@arm.com>,
Huacai Chen <chenhuacai@kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Dinh Nguyen <dinguyen@kernel.org>,
Jonas Bonn <jonas@southpole.se>,
David Hildenbrand <david@redhat.com>,
Claudio Imbrenda <imbrenda@linux.ibm.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
"David S. Miller" <davem@davemloft.net>,
Richard Weinberger <richard@nod.at>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Dave Hansen <dave.hansen@linux.intel.com>,
Arnd Bergmann <arnd@arndb.de>,
Christophe Leroy <christophe.leroy@csgroup.eu>
Subject: Re: [PATCH mm-unstable v7 00/31] Split ptdesc from struct page
Date: Wed, 26 Jul 2023 15:34:17 +0100 [thread overview]
Message-ID: <ZMEu6VcTqPj69bQ7@casper.infradead.org> (raw)
In-Reply-To: <5296514f-cdd1-9526-2e83-a21e76e86e5@google.com>
On Mon, Jul 24, 2023 at 09:41:36PM -0700, Hugh Dickins wrote:
> On Mon, 24 Jul 2023, Vishal Moola (Oracle) wrote:
>
> > The MM subsystem is trying to shrink struct page. This patchset
> > introduces a memory descriptor for page table tracking - struct ptdesc.
> >
> > This patchset introduces ptdesc, splits ptdesc from struct page, and
> > converts many callers of page table constructor/destructors to use ptdescs.
> >
> > Ptdesc is a foundation to further standardize page tables, and eventually
> > allow for dynamic allocation of page tables independent of struct page.
> > However, the use of pages for page table tracking is quite deeply
> > ingrained and varied across archictectures, so there is still a lot of
> > work to be done before that can happen.
>
> Others may differ, but it remains the case that I see no point to this
> patchset, until the minimal descriptor that replaces struct page is
> working, and struct page then becomes just overhead. Until that time,
> let architectures continue to use struct page as they do - whyever not?
Because it's easier for architecture maintainers to understand what they
should and shouldn't be using. Look at the definition:
+struct ptdesc {
+ unsigned long __page_flags;
+
+ union {
+ struct rcu_head pt_rcu_head;
+ struct list_head pt_list;
+ struct {
+ unsigned long _pt_pad_1;
+ pgtable_t pmd_huge_pte;
+ };
+ };
+ unsigned long __page_mapping;
+
+ union {
+ struct mm_struct *pt_mm;
+ atomic_t pt_frag_refcount;
+ };
+
+ union {
+ unsigned long _pt_pad_2;
+#if ALLOC_SPLIT_PTLOCKS
+ spinlock_t *ptl;
+#else
+ spinlock_t ptl;
+#endif
+ };
+ unsigned int __page_type;
+ atomic_t _refcount;
+#ifdef CONFIG_MEMCG
+ unsigned long pt_memcg_data;
+#endif
+};
It's still a 31-line struct definition, I'll grant you. But it's far
easier to comprehend than the definition of struct page (~140 lines).
An architecture maintainer can look at it and see what might be available,
and what is already used. And hopefully we'll have less "Oh, I'll just
use page->private". It's really not fair to expect arch maintainers to
learn so much about the mm.
It's still messier than I would like, but I don't think we can do better
for now. I don't understand why you're so interested in delaying doing
this work.
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Wilcox <willy@infradead.org>
To: Hugh Dickins <hughd@google.com>
Cc: "Vishal Moola (Oracle)" <vishal.moola@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-arch@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org,
linux-hexagon@vger.kernel.org, loongarch@lists.linux.dev,
linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
linux-openrisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
linux-um@lists.infradead.org, xen-devel@lists.xenproject.org,
kvm@vger.kernel.org, Catalin Marinas <catalin.marinas@arm.com>,
Huacai Chen <chenhuacai@kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Dinh Nguyen <dinguyen@kernel.org>,
Jonas Bonn <jonas@southpole.se>,
David Hildenbrand <david@redhat.com>,
Claudio Imbrenda <imbrenda@linux.ibm.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
"David S. Miller" <davem@davemloft.net>,
Richard Weinberger <richard@nod.at>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Dave Hansen <dave.hansen@linux.intel.com>,
Arnd Bergmann <arnd@arndb.de>,
Christophe Leroy <christophe.leroy@csgroup.eu>
Subject: Re: [PATCH mm-unstable v7 00/31] Split ptdesc from struct page
Date: Wed, 26 Jul 2023 15:34:17 +0100 [thread overview]
Message-ID: <ZMEu6VcTqPj69bQ7@casper.infradead.org> (raw)
In-Reply-To: <5296514f-cdd1-9526-2e83-a21e76e86e5@google.com>
On Mon, Jul 24, 2023 at 09:41:36PM -0700, Hugh Dickins wrote:
> On Mon, 24 Jul 2023, Vishal Moola (Oracle) wrote:
>
> > The MM subsystem is trying to shrink struct page. This patchset
> > introduces a memory descriptor for page table tracking - struct ptdesc.
> >
> > This patchset introduces ptdesc, splits ptdesc from struct page, and
> > converts many callers of page table constructor/destructors to use ptdescs.
> >
> > Ptdesc is a foundation to further standardize page tables, and eventually
> > allow for dynamic allocation of page tables independent of struct page.
> > However, the use of pages for page table tracking is quite deeply
> > ingrained and varied across archictectures, so there is still a lot of
> > work to be done before that can happen.
>
> Others may differ, but it remains the case that I see no point to this
> patchset, until the minimal descriptor that replaces struct page is
> working, and struct page then becomes just overhead. Until that time,
> let architectures continue to use struct page as they do - whyever not?
Because it's easier for architecture maintainers to understand what they
should and shouldn't be using. Look at the definition:
+struct ptdesc {
+ unsigned long __page_flags;
+
+ union {
+ struct rcu_head pt_rcu_head;
+ struct list_head pt_list;
+ struct {
+ unsigned long _pt_pad_1;
+ pgtable_t pmd_huge_pte;
+ };
+ };
+ unsigned long __page_mapping;
+
+ union {
+ struct mm_struct *pt_mm;
+ atomic_t pt_frag_refcount;
+ };
+
+ union {
+ unsigned long _pt_pad_2;
+#if ALLOC_SPLIT_PTLOCKS
+ spinlock_t *ptl;
+#else
+ spinlock_t ptl;
+#endif
+ };
+ unsigned int __page_type;
+ atomic_t _refcount;
+#ifdef CONFIG_MEMCG
+ unsigned long pt_memcg_data;
+#endif
+};
It's still a 31-line struct definition, I'll grant you. But it's far
easier to comprehend than the definition of struct page (~140 lines).
An architecture maintainer can look at it and see what might be available,
and what is already used. And hopefully we'll have less "Oh, I'll just
use page->private". It's really not fair to expect arch maintainers to
learn so much about the mm.
It's still messier than I would like, but I don't think we can do better
for now. I don't understand why you're so interested in delaying doing
this work.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Wilcox <willy@infradead.org>
To: Hugh Dickins <hughd@google.com>
Cc: "Vishal Moola (Oracle)" <vishal.moola@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-arch@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org,
linux-hexagon@vger.kernel.org, loongarch@lists.linux.dev,
linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
linux-openrisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
linux-um@lists.infradead.org, xen-devel@lists.xenproject.org,
kvm@vger.kernel.org, Catalin Marinas <catalin.marinas@arm.com>,
Huacai Chen <chenhuacai@kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Dinh Nguyen <dinguyen@kernel.org>,
Jonas Bonn <jonas@southpole.se>,
David Hildenbrand <david@redhat.com>,
Claudio Imbrenda <imbrenda@linux.ibm.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
"David S. Miller" <davem@davemloft.net>,
Richard Weinberger <richard@nod.at>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Dave Hansen <dave.hansen@linux.intel.com>,
Arnd Bergmann <arnd@arndb.de>,
Christophe Leroy <christophe.leroy@csgroup.eu>
Subject: Re: [PATCH mm-unstable v7 00/31] Split ptdesc from struct page
Date: Wed, 26 Jul 2023 15:34:17 +0100 [thread overview]
Message-ID: <ZMEu6VcTqPj69bQ7@casper.infradead.org> (raw)
In-Reply-To: <5296514f-cdd1-9526-2e83-a21e76e86e5@google.com>
On Mon, Jul 24, 2023 at 09:41:36PM -0700, Hugh Dickins wrote:
> On Mon, 24 Jul 2023, Vishal Moola (Oracle) wrote:
>
> > The MM subsystem is trying to shrink struct page. This patchset
> > introduces a memory descriptor for page table tracking - struct ptdesc.
> >
> > This patchset introduces ptdesc, splits ptdesc from struct page, and
> > converts many callers of page table constructor/destructors to use ptdescs.
> >
> > Ptdesc is a foundation to further standardize page tables, and eventually
> > allow for dynamic allocation of page tables independent of struct page.
> > However, the use of pages for page table tracking is quite deeply
> > ingrained and varied across archictectures, so there is still a lot of
> > work to be done before that can happen.
>
> Others may differ, but it remains the case that I see no point to this
> patchset, until the minimal descriptor that replaces struct page is
> working, and struct page then becomes just overhead. Until that time,
> let architectures continue to use struct page as they do - whyever not?
Because it's easier for architecture maintainers to understand what they
should and shouldn't be using. Look at the definition:
+struct ptdesc {
+ unsigned long __page_flags;
+
+ union {
+ struct rcu_head pt_rcu_head;
+ struct list_head pt_list;
+ struct {
+ unsigned long _pt_pad_1;
+ pgtable_t pmd_huge_pte;
+ };
+ };
+ unsigned long __page_mapping;
+
+ union {
+ struct mm_struct *pt_mm;
+ atomic_t pt_frag_refcount;
+ };
+
+ union {
+ unsigned long _pt_pad_2;
+#if ALLOC_SPLIT_PTLOCKS
+ spinlock_t *ptl;
+#else
+ spinlock_t ptl;
+#endif
+ };
+ unsigned int __page_type;
+ atomic_t _refcount;
+#ifdef CONFIG_MEMCG
+ unsigned long pt_memcg_data;
+#endif
+};
It's still a 31-line struct definition, I'll grant you. But it's far
easier to comprehend than the definition of struct page (~140 lines).
An architecture maintainer can look at it and see what might be available,
and what is already used. And hopefully we'll have less "Oh, I'll just
use page->private". It's really not fair to expect arch maintainers to
learn so much about the mm.
It's still messier than I would like, but I don't think we can do better
for now. I don't understand why you're so interested in delaying doing
this work.
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Wilcox <willy@infradead.org>
To: Hugh Dickins <hughd@google.com>
Cc: kvm@vger.kernel.org, linux-sh@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
David Hildenbrand <david@redhat.com>,
linux-openrisc@vger.kernel.org, sparclinux@vger.kernel.org,
linux-riscv@lists.infradead.org,
Claudio Imbrenda <imbrenda@linux.ibm.com>,
linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
Yoshinori Sato <ysato@users.sourceforge.jp>,
linux-hexagon@vger.kernel.org,
Huacai Chen <chenhuacai@kernel.org>,
linux-csky@vger.kernel.org,
Geert Uytterhoeven <geert@linux-m68k.org>,
xen-devel@lists.xenproject.org, Jonas Bonn <jonas@southpole.se>,
Arnd Bergmann <arnd@arndb.de>,
linux-um@lists.infradead.org, linux-m68k@lists.linux-m68k.org,
loongarch@lists.linux.dev,
Paul Walmsley <paul.walmsley@sifive.com>,
linux-arm-kernel@lists.infradead.org,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
linux-mm@kvack.org, linux-mips@vger.kernel.org,
"Vishal Moola \(Oracle\)" <vishal.moola@gmail.com>,
Dinh Nguyen <dinguyen@kernel.org >,
Richard Weinberger <richard@nod.at>,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH mm-unstable v7 00/31] Split ptdesc from struct page
Date: Wed, 26 Jul 2023 15:34:17 +0100 [thread overview]
Message-ID: <ZMEu6VcTqPj69bQ7@casper.infradead.org> (raw)
In-Reply-To: <5296514f-cdd1-9526-2e83-a21e76e86e5@google.com>
On Mon, Jul 24, 2023 at 09:41:36PM -0700, Hugh Dickins wrote:
> On Mon, 24 Jul 2023, Vishal Moola (Oracle) wrote:
>
> > The MM subsystem is trying to shrink struct page. This patchset
> > introduces a memory descriptor for page table tracking - struct ptdesc.
> >
> > This patchset introduces ptdesc, splits ptdesc from struct page, and
> > converts many callers of page table constructor/destructors to use ptdescs.
> >
> > Ptdesc is a foundation to further standardize page tables, and eventually
> > allow for dynamic allocation of page tables independent of struct page.
> > However, the use of pages for page table tracking is quite deeply
> > ingrained and varied across archictectures, so there is still a lot of
> > work to be done before that can happen.
>
> Others may differ, but it remains the case that I see no point to this
> patchset, until the minimal descriptor that replaces struct page is
> working, and struct page then becomes just overhead. Until that time,
> let architectures continue to use struct page as they do - whyever not?
Because it's easier for architecture maintainers to understand what they
should and shouldn't be using. Look at the definition:
+struct ptdesc {
+ unsigned long __page_flags;
+
+ union {
+ struct rcu_head pt_rcu_head;
+ struct list_head pt_list;
+ struct {
+ unsigned long _pt_pad_1;
+ pgtable_t pmd_huge_pte;
+ };
+ };
+ unsigned long __page_mapping;
+
+ union {
+ struct mm_struct *pt_mm;
+ atomic_t pt_frag_refcount;
+ };
+
+ union {
+ unsigned long _pt_pad_2;
+#if ALLOC_SPLIT_PTLOCKS
+ spinlock_t *ptl;
+#else
+ spinlock_t ptl;
+#endif
+ };
+ unsigned int __page_type;
+ atomic_t _refcount;
+#ifdef CONFIG_MEMCG
+ unsigned long pt_memcg_data;
+#endif
+};
It's still a 31-line struct definition, I'll grant you. But it's far
easier to comprehend than the definition of struct page (~140 lines).
An architecture maintainer can look at it and see what might be available,
and what is already used. And hopefully we'll have less "Oh, I'll just
use page->private". It's really not fair to expect arch maintainers to
learn so much about the mm.
It's still messier than I would like, but I don't think we can do better
for now. I don't understand why you're so interested in delaying doing
this work.
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Wilcox <willy@infradead.org>
To: Hugh Dickins <hughd@google.com>
Cc: "Vishal Moola (Oracle)" <vishal.moola@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-arch@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org,
linux-hexagon@vger.kernel.org, loongarch@lists.linux.dev,
linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
linux-openrisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
linux-um@lists.infradead.org, xen-devel@lists.xenproject.org,
kvm@vger.kernel.org, Catalin Marinas <catalin.marinas@arm.com>,
Huacai Chen <chenhuacai@kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Dinh Nguyen <dinguyen@kernel.org>,
Jonas Bonn <jonas@southpole.se>,
David Hildenbrand <david@redhat.com>,
Claudio
Subject: Re: [PATCH mm-unstable v7 00/31] Split ptdesc from struct page
Date: Wed, 26 Jul 2023 15:34:17 +0100 [thread overview]
Message-ID: <ZMEu6VcTqPj69bQ7@casper.infradead.org> (raw)
In-Reply-To: <5296514f-cdd1-9526-2e83-a21e76e86e5@google.com>
On Mon, Jul 24, 2023 at 09:41:36PM -0700, Hugh Dickins wrote:
> On Mon, 24 Jul 2023, Vishal Moola (Oracle) wrote:
>
> > The MM subsystem is trying to shrink struct page. This patchset
> > introduces a memory descriptor for page table tracking - struct ptdesc.
> >
> > This patchset introduces ptdesc, splits ptdesc from struct page, and
> > converts many callers of page table constructor/destructors to use ptdescs.
> >
> > Ptdesc is a foundation to further standardize page tables, and eventually
> > allow for dynamic allocation of page tables independent of struct page.
> > However, the use of pages for page table tracking is quite deeply
> > ingrained and varied across archictectures, so there is still a lot of
> > work to be done before that can happen.
>
> Others may differ, but it remains the case that I see no point to this
> patchset, until the minimal descriptor that replaces struct page is
> working, and struct page then becomes just overhead. Until that time,
> let architectures continue to use struct page as they do - whyever not?
Because it's easier for architecture maintainers to understand what they
should and shouldn't be using. Look at the definition:
+struct ptdesc {
+ unsigned long __page_flags;
+
+ union {
+ struct rcu_head pt_rcu_head;
+ struct list_head pt_list;
+ struct {
+ unsigned long _pt_pad_1;
+ pgtable_t pmd_huge_pte;
+ };
+ };
+ unsigned long __page_mapping;
+
+ union {
+ struct mm_struct *pt_mm;
+ atomic_t pt_frag_refcount;
+ };
+
+ union {
+ unsigned long _pt_pad_2;
+#if ALLOC_SPLIT_PTLOCKS
+ spinlock_t *ptl;
+#else
+ spinlock_t ptl;
+#endif
+ };
+ unsigned int __page_type;
+ atomic_t _refcount;
+#ifdef CONFIG_MEMCG
+ unsigned long pt_memcg_data;
+#endif
+};
It's still a 31-line struct definition, I'll grant you. But it's far
easier to comprehend than the definition of struct page (~140 lines).
An architecture maintainer can look at it and see what might be available,
and what is already used. And hopefully we'll have less "Oh, I'll just
use page->private". It's really not fair to expect arch maintainers to
learn so much about the mm.
It's still messier than I would like, but I don't think we can do better
for now. I don't understand why you're so interested in delaying doing
this work.
next prev parent reply other threads:[~2023-07-26 14:34 UTC|newest]
Thread overview: 143+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-25 4:20 [PATCH mm-unstable v7 00/31] Split ptdesc from struct page Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 01/31] mm: Add PAGE_TYPE_OP folio functions Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 02/31] pgtable: Create struct ptdesc Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 03/31] mm: add utility functions for ptdesc Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 04/31] mm: Convert pmd_pgtable_page() callers to use pmd_ptdesc() Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 05/31] mm: Convert ptlock_alloc() to use ptdescs Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 06/31] mm: Convert ptlock_ptr() " Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 07/31] mm: Convert pmd_ptlock_init() " Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 08/31] mm: Convert ptlock_init() " Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 09/31] mm: Convert pmd_ptlock_free() " Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 10/31] mm: Convert ptlock_free() " Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 11/31] mm: Create ptdesc equivalents for pgtable_{pte,pmd}_page_{ctor,dtor} Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 12/31] powerpc: Convert various functions to use ptdescs Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 23:33 ` kernel test robot
2023-07-25 23:33 ` kernel test robot
2023-07-25 23:33 ` kernel test robot
2023-07-25 23:33 ` kernel test robot
2023-07-25 4:20 ` [PATCH mm-unstable v7 13/31] x86: " Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 14/31] s390: Convert various pgalloc " Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 15/31] mm: Remove page table members from struct page Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 16/31] pgalloc: Convert various functions to use ptdescs Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 17/31] arm: " Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 18/31] arm64: " Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 19/31] csky: Convert __pte_free_tlb() " Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 20/31] hexagon: " Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 21/31] loongarch: Convert various functions " Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 22/31] m68k: " Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 23/31] mips: " Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 24/31] nios2: Convert __pte_free_tlb() " Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 25/31] openrisc: " Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 26/31] riscv: Convert alloc_{pmd, pte}_late() " Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 27/31] sh: Convert pte_free_tlb() " Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 28/31] sparc64: Convert various functions " Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 29/31] sparc: Convert pgtable_pte_page_{ctor, dtor}() to ptdesc equivalents Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 30/31] um: Convert {pmd, pte}_free_tlb() to use ptdescs Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` [PATCH mm-unstable v7 31/31] mm: Remove pgtable_{pmd, pte}_page_{ctor, dtor}() wrappers Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:20 ` Vishal Moola (Oracle)
2023-07-25 4:41 ` [PATCH mm-unstable v7 00/31] Split ptdesc from struct page Hugh Dickins
2023-07-25 4:41 ` Hugh Dickins
2023-07-25 4:41 ` Hugh Dickins
2023-07-25 4:41 ` Hugh Dickins
2023-07-25 4:41 ` Hugh Dickins
2023-07-26 14:34 ` Matthew Wilcox [this message]
2023-07-26 14:34 ` Matthew Wilcox
2023-07-26 14:34 ` Matthew Wilcox
2023-07-26 14:34 ` Matthew Wilcox
2023-07-26 14:34 ` Matthew Wilcox
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=ZMEu6VcTqPj69bQ7@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=chenhuacai@kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=david@redhat.com \
--cc=dinguyen@kernel.org \
--cc=geert@linux-m68k.org \
--cc=hughd@google.com \
--cc=imbrenda@linux.ibm.com \
--cc=jonas@southpole.se \
--cc=kvm@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-hexagon@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-openrisc@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=loongarch@lists.linux.dev \
--cc=paul.walmsley@sifive.com \
--cc=richard@nod.at \
--cc=sparclinux@vger.kernel.org \
--cc=tsbogend@alpha.franken.de \
--cc=vishal.moola@gmail.com \
--cc=xen-devel@lists.xenproject.org \
--cc=ysato@users.sourceforge.jp \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.