From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
To: David Hildenbrand <david@redhat.com>,
Ryan Roberts <ryan.roberts@arm.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Matthew Wilcox <willy@infradead.org>,
Russell King <linux@armlinux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Dinh Nguyen <dinguyen@kernel.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
"Naveen N. Rao" <naveen.n.rao@linux.ibm.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Gerald Schaefer <gerald.schaefer@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
"David S. Miller" <davem@davemloft.net>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-riscv@lists.infradead.org"
<linux-riscv@lists.infradead.org>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>
Subject: Re: [PATCH v1 01/11] arm/pgtable: define PFN_PTE_SHIFT on arm and arm64
Date: Wed, 24 Jan 2024 11:15:03 +0530 [thread overview]
Message-ID: <8734unqo80.fsf@kernel.org> (raw)
In-Reply-To: <794c1dc3-520c-4030-b0fe-e24782576347@redhat.com>
David Hildenbrand <david@redhat.com> writes:
> On 23.01.24 12:38, Ryan Roberts wrote:
>> On 23/01/2024 11:31, David Hildenbrand wrote:
>>>>>
>>>>>> If high bits are used for
>>>>>> something else, then we might produce a garbage PTE on overflow, but that
>>>>>> shouldn't really matter I concluded for folio_pte_batch() purposes, we'd not
>>>>>> detect "belongs to this folio batch" either way.
>>>>>
>>>>> Exactly.
>>>>>
>>>>>>
>>>>>> Maybe it's likely cleaner to also have a custom pte_next_pfn() on ppc, I just
>>>>>> hope that we don't lose any other arbitrary PTE bits by doing the pte_pgprot().
>>>>>
>>>>> I don't see the need for ppc to implement pte_next_pfn().
>>>>
>>>> Agreed.
>>>
>>> So likely we should then do on top for powerpc (whitespace damage):
>>>
>>> diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
>>> index a04ae4449a025..549a440ed7f65 100644
>>> --- a/arch/powerpc/mm/pgtable.c
>>> +++ b/arch/powerpc/mm/pgtable.c
>>> @@ -220,10 +220,7 @@ void set_ptes(struct mm_struct *mm, unsigned long addr,
>>> pte_t *ptep,
>>> break;
>>> ptep++;
>>> addr += PAGE_SIZE;
>>> - /*
>>> - * increment the pfn.
>>> - */
>>> - pte = pfn_pte(pte_pfn(pte) + 1, pte_pgprot((pte)));
>>> + pte = pte_next_pfn(pte);
>>> }
>>> }
>>
>> Looks like commit 47b8def9358c ("powerpc/mm: Avoid calling
>> arch_enter/leave_lazy_mmu() in set_ptes") changed from doing the simple
>> increment to this more complex approach, but the log doesn't say why.
>
> @Aneesh, was that change on purpose?
>
Because we had a bug with the patch that introduced the change and that
line was confusing. The right thing should have been to add
pte_pfn_next() to make it clear. It was confusing because not all pte
format had pfn at PAGE_SHIFT offset (even though we did use the correct
PTE_RPN_SHIFT in this specific case). To make it simpler I ended up
switching that line to pte_pfn(pte) + 1 .
-aneesh
_______________________________________________
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: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
To: David Hildenbrand <david@redhat.com>,
Ryan Roberts <ryan.roberts@arm.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Matthew Wilcox <willy@infradead.org>,
Russell King <linux@armlinux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Dinh Nguyen <dinguyen@kernel.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
"Naveen N. Rao" <naveen.n.rao@linux.ibm.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Gerald Schaefer <gerald.schaefer@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
"David S. Miller" <davem@davemloft.net>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-riscv@lists.infradead.org"
<linux-riscv@lists.infradead.org>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>
Subject: Re: [PATCH v1 01/11] arm/pgtable: define PFN_PTE_SHIFT on arm and arm64
Date: Wed, 24 Jan 2024 11:15:03 +0530 [thread overview]
Message-ID: <8734unqo80.fsf@kernel.org> (raw)
In-Reply-To: <794c1dc3-520c-4030-b0fe-e24782576347@redhat.com>
David Hildenbrand <david@redhat.com> writes:
> On 23.01.24 12:38, Ryan Roberts wrote:
>> On 23/01/2024 11:31, David Hildenbrand wrote:
>>>>>
>>>>>> If high bits are used for
>>>>>> something else, then we might produce a garbage PTE on overflow, but that
>>>>>> shouldn't really matter I concluded for folio_pte_batch() purposes, we'd not
>>>>>> detect "belongs to this folio batch" either way.
>>>>>
>>>>> Exactly.
>>>>>
>>>>>>
>>>>>> Maybe it's likely cleaner to also have a custom pte_next_pfn() on ppc, I just
>>>>>> hope that we don't lose any other arbitrary PTE bits by doing the pte_pgprot().
>>>>>
>>>>> I don't see the need for ppc to implement pte_next_pfn().
>>>>
>>>> Agreed.
>>>
>>> So likely we should then do on top for powerpc (whitespace damage):
>>>
>>> diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
>>> index a04ae4449a025..549a440ed7f65 100644
>>> --- a/arch/powerpc/mm/pgtable.c
>>> +++ b/arch/powerpc/mm/pgtable.c
>>> @@ -220,10 +220,7 @@ void set_ptes(struct mm_struct *mm, unsigned long addr,
>>> pte_t *ptep,
>>> break;
>>> ptep++;
>>> addr += PAGE_SIZE;
>>> - /*
>>> - * increment the pfn.
>>> - */
>>> - pte = pfn_pte(pte_pfn(pte) + 1, pte_pgprot((pte)));
>>> + pte = pte_next_pfn(pte);
>>> }
>>> }
>>
>> Looks like commit 47b8def9358c ("powerpc/mm: Avoid calling
>> arch_enter/leave_lazy_mmu() in set_ptes") changed from doing the simple
>> increment to this more complex approach, but the log doesn't say why.
>
> @Aneesh, was that change on purpose?
>
Because we had a bug with the patch that introduced the change and that
line was confusing. The right thing should have been to add
pte_pfn_next() to make it clear. It was confusing because not all pte
format had pfn at PAGE_SHIFT offset (even though we did use the correct
PTE_RPN_SHIFT in this specific case). To make it simpler I ended up
switching that line to pte_pfn(pte) + 1 .
-aneesh
WARNING: multiple messages have this Message-ID (diff)
From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
To: David Hildenbrand <david@redhat.com>,
Ryan Roberts <ryan.roberts@arm.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Will Deacon <will@kernel.org>,
"linux-riscv@lists.infradead.org"
<linux-riscv@lists.infradead.org>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
Russell King <linux@armlinux.org.uk>,
Matthew Wilcox <willy@infradead.org>,
"Naveen N. Rao" <naveen.n.rao@linux.ibm.com>,
Gerald Schaefer <gerald.schaefer@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Vasily Gorbik <gor@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Nicholas Piggin <npiggin@gmail.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Dinh Nguyen <dinguyen@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Sven Schnelle <svens@linux.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
"linuxpp c-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH v1 01/11] arm/pgtable: define PFN_PTE_SHIFT on arm and arm64
Date: Wed, 24 Jan 2024 11:15:03 +0530 [thread overview]
Message-ID: <8734unqo80.fsf@kernel.org> (raw)
In-Reply-To: <794c1dc3-520c-4030-b0fe-e24782576347@redhat.com>
David Hildenbrand <david@redhat.com> writes:
> On 23.01.24 12:38, Ryan Roberts wrote:
>> On 23/01/2024 11:31, David Hildenbrand wrote:
>>>>>
>>>>>> If high bits are used for
>>>>>> something else, then we might produce a garbage PTE on overflow, but that
>>>>>> shouldn't really matter I concluded for folio_pte_batch() purposes, we'd not
>>>>>> detect "belongs to this folio batch" either way.
>>>>>
>>>>> Exactly.
>>>>>
>>>>>>
>>>>>> Maybe it's likely cleaner to also have a custom pte_next_pfn() on ppc, I just
>>>>>> hope that we don't lose any other arbitrary PTE bits by doing the pte_pgprot().
>>>>>
>>>>> I don't see the need for ppc to implement pte_next_pfn().
>>>>
>>>> Agreed.
>>>
>>> So likely we should then do on top for powerpc (whitespace damage):
>>>
>>> diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
>>> index a04ae4449a025..549a440ed7f65 100644
>>> --- a/arch/powerpc/mm/pgtable.c
>>> +++ b/arch/powerpc/mm/pgtable.c
>>> @@ -220,10 +220,7 @@ void set_ptes(struct mm_struct *mm, unsigned long addr,
>>> pte_t *ptep,
>>> break;
>>> ptep++;
>>> addr += PAGE_SIZE;
>>> - /*
>>> - * increment the pfn.
>>> - */
>>> - pte = pfn_pte(pte_pfn(pte) + 1, pte_pgprot((pte)));
>>> + pte = pte_next_pfn(pte);
>>> }
>>> }
>>
>> Looks like commit 47b8def9358c ("powerpc/mm: Avoid calling
>> arch_enter/leave_lazy_mmu() in set_ptes") changed from doing the simple
>> increment to this more complex approach, but the log doesn't say why.
>
> @Aneesh, was that change on purpose?
>
Because we had a bug with the patch that introduced the change and that
line was confusing. The right thing should have been to add
pte_pfn_next() to make it clear. It was confusing because not all pte
format had pfn at PAGE_SHIFT offset (even though we did use the correct
PTE_RPN_SHIFT in this specific case). To make it simpler I ended up
switching that line to pte_pfn(pte) + 1 .
-aneesh
WARNING: multiple messages have this Message-ID (diff)
From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
To: David Hildenbrand <david@redhat.com>,
Ryan Roberts <ryan.roberts@arm.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Matthew Wilcox <willy@infradead.org>,
Russell King <linux@armlinux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Dinh Nguyen <dinguyen@kernel.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
"Naveen N. Rao" <naveen.n.rao@linux.ibm.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Gerald Schaefer <gerald.schaefer@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
"David S. Miller" <davem@davemloft.net>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-riscv@lists.infradead.org"
<linux-riscv@lists.infradead.org>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>
Subject: Re: [PATCH v1 01/11] arm/pgtable: define PFN_PTE_SHIFT on arm and arm64
Date: Wed, 24 Jan 2024 11:15:03 +0530 [thread overview]
Message-ID: <8734unqo80.fsf@kernel.org> (raw)
In-Reply-To: <794c1dc3-520c-4030-b0fe-e24782576347@redhat.com>
David Hildenbrand <david@redhat.com> writes:
> On 23.01.24 12:38, Ryan Roberts wrote:
>> On 23/01/2024 11:31, David Hildenbrand wrote:
>>>>>
>>>>>> If high bits are used for
>>>>>> something else, then we might produce a garbage PTE on overflow, but that
>>>>>> shouldn't really matter I concluded for folio_pte_batch() purposes, we'd not
>>>>>> detect "belongs to this folio batch" either way.
>>>>>
>>>>> Exactly.
>>>>>
>>>>>>
>>>>>> Maybe it's likely cleaner to also have a custom pte_next_pfn() on ppc, I just
>>>>>> hope that we don't lose any other arbitrary PTE bits by doing the pte_pgprot().
>>>>>
>>>>> I don't see the need for ppc to implement pte_next_pfn().
>>>>
>>>> Agreed.
>>>
>>> So likely we should then do on top for powerpc (whitespace damage):
>>>
>>> diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
>>> index a04ae4449a025..549a440ed7f65 100644
>>> --- a/arch/powerpc/mm/pgtable.c
>>> +++ b/arch/powerpc/mm/pgtable.c
>>> @@ -220,10 +220,7 @@ void set_ptes(struct mm_struct *mm, unsigned long addr,
>>> pte_t *ptep,
>>> break;
>>> ptep++;
>>> addr += PAGE_SIZE;
>>> - /*
>>> - * increment the pfn.
>>> - */
>>> - pte = pfn_pte(pte_pfn(pte) + 1, pte_pgprot((pte)));
>>> + pte = pte_next_pfn(pte);
>>> }
>>> }
>>
>> Looks like commit 47b8def9358c ("powerpc/mm: Avoid calling
>> arch_enter/leave_lazy_mmu() in set_ptes") changed from doing the simple
>> increment to this more complex approach, but the log doesn't say why.
>
> @Aneesh, was that change on purpose?
>
Because we had a bug with the patch that introduced the change and that
line was confusing. The right thing should have been to add
pte_pfn_next() to make it clear. It was confusing because not all pte
format had pfn at PAGE_SHIFT offset (even though we did use the correct
PTE_RPN_SHIFT in this specific case). To make it simpler I ended up
switching that line to pte_pfn(pte) + 1 .
-aneesh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-01-24 5:45 UTC|newest]
Thread overview: 196+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 19:41 [PATCH v1 00/11] mm/memory: optimize fork() with PTE-mapped THP David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` [PATCH v1 01/11] arm/pgtable: define PFN_PTE_SHIFT on arm and arm64 David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-23 10:34 ` Ryan Roberts
2024-01-23 10:34 ` Ryan Roberts
2024-01-23 10:34 ` Ryan Roberts
2024-01-23 10:34 ` Ryan Roberts
2024-01-23 10:48 ` David Hildenbrand
2024-01-23 10:48 ` David Hildenbrand
2024-01-23 10:48 ` David Hildenbrand
2024-01-23 10:48 ` David Hildenbrand
2024-01-23 11:02 ` David Hildenbrand
2024-01-23 11:02 ` David Hildenbrand
2024-01-23 11:02 ` David Hildenbrand
2024-01-23 11:02 ` David Hildenbrand
2024-01-23 11:17 ` Ryan Roberts
2024-01-23 11:17 ` Ryan Roberts
2024-01-23 11:17 ` Ryan Roberts
2024-01-23 11:17 ` Ryan Roberts
2024-01-23 11:33 ` David Hildenbrand
2024-01-23 11:33 ` David Hildenbrand
2024-01-23 11:33 ` David Hildenbrand
2024-01-23 11:33 ` David Hildenbrand
2024-01-23 11:44 ` Ryan Roberts
2024-01-23 11:44 ` Ryan Roberts
2024-01-23 11:44 ` Ryan Roberts
2024-01-23 11:44 ` Ryan Roberts
2024-01-23 11:08 ` Ryan Roberts
2024-01-23 11:08 ` Ryan Roberts
2024-01-23 11:08 ` Ryan Roberts
2024-01-23 11:08 ` Ryan Roberts
2024-01-23 11:16 ` Christophe Leroy
2024-01-23 11:16 ` Christophe Leroy
2024-01-23 11:16 ` Christophe Leroy
2024-01-23 11:16 ` Christophe Leroy
2024-01-23 11:31 ` David Hildenbrand
2024-01-23 11:31 ` David Hildenbrand
2024-01-23 11:31 ` David Hildenbrand
2024-01-23 11:31 ` David Hildenbrand
2024-01-23 11:38 ` Ryan Roberts
2024-01-23 11:38 ` Ryan Roberts
2024-01-23 11:38 ` Ryan Roberts
2024-01-23 11:38 ` Ryan Roberts
2024-01-23 11:40 ` David Hildenbrand
2024-01-23 11:40 ` David Hildenbrand
2024-01-23 11:40 ` David Hildenbrand
2024-01-23 11:40 ` David Hildenbrand
2024-01-24 5:45 ` Aneesh Kumar K.V [this message]
2024-01-24 5:45 ` Aneesh Kumar K.V
2024-01-24 5:45 ` Aneesh Kumar K.V
2024-01-24 5:45 ` Aneesh Kumar K.V
2024-01-23 11:48 ` Christophe Leroy
2024-01-23 11:48 ` Christophe Leroy
2024-01-23 11:48 ` Christophe Leroy
2024-01-23 11:48 ` Christophe Leroy
2024-01-23 11:53 ` David Hildenbrand
2024-01-23 11:53 ` David Hildenbrand
2024-01-23 11:53 ` David Hildenbrand
2024-01-23 11:53 ` David Hildenbrand
2024-01-24 5:46 ` Aneesh Kumar K.V
2024-01-24 5:46 ` Aneesh Kumar K.V
2024-01-24 5:46 ` Aneesh Kumar K.V
2024-01-24 5:46 ` Aneesh Kumar K.V
2024-01-23 11:10 ` Christophe Leroy
2024-01-23 11:10 ` Christophe Leroy
2024-01-23 11:10 ` Christophe Leroy
2024-01-23 11:10 ` Christophe Leroy
2024-01-23 15:01 ` Matthew Wilcox
2024-01-23 15:01 ` Matthew Wilcox
2024-01-23 15:01 ` Matthew Wilcox
2024-01-23 15:01 ` Matthew Wilcox
2024-01-23 15:22 ` Ryan Roberts
2024-01-23 15:22 ` Ryan Roberts
2024-01-23 15:22 ` Ryan Roberts
2024-01-23 15:22 ` Ryan Roberts
2024-01-22 19:41 ` [PATCH v1 02/11] nios2/pgtable: define PFN_PTE_SHIFT David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` [PATCH v1 03/11] powerpc/pgtable: " David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` [PATCH v1 04/11] risc: pgtable: " David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 20:03 ` Alexandre Ghiti
2024-01-22 20:03 ` Alexandre Ghiti
2024-01-22 20:03 ` Alexandre Ghiti
2024-01-22 20:03 ` Alexandre Ghiti
2024-01-22 20:08 ` David Hildenbrand
2024-01-22 20:08 ` David Hildenbrand
2024-01-22 20:08 ` David Hildenbrand
2024-01-22 20:08 ` David Hildenbrand
2024-01-22 19:41 ` [PATCH v1 05/11] s390/pgtable: " David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` [PATCH v1 06/11] sparc/pgtable: " David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` [PATCH v1 07/11] mm/memory: factor out copying the actual PTE in copy_present_pte() David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-23 10:45 ` Ryan Roberts
2024-01-23 10:45 ` Ryan Roberts
2024-01-23 10:45 ` Ryan Roberts
2024-01-23 10:45 ` Ryan Roberts
2024-01-22 19:41 ` [PATCH v1 08/11] mm/memory: pass PTE to copy_present_pte() David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-23 10:47 ` Ryan Roberts
2024-01-23 10:47 ` Ryan Roberts
2024-01-23 10:47 ` Ryan Roberts
2024-01-23 10:47 ` Ryan Roberts
2024-01-22 19:41 ` [PATCH v1 09/11] mm/memory: optimize fork() with PTE-mapped THP David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-23 12:01 ` Ryan Roberts
2024-01-23 12:01 ` Ryan Roberts
2024-01-23 12:01 ` Ryan Roberts
2024-01-23 12:01 ` Ryan Roberts
2024-01-23 12:19 ` David Hildenbrand
2024-01-23 12:19 ` David Hildenbrand
2024-01-23 12:19 ` David Hildenbrand
2024-01-23 12:19 ` David Hildenbrand
2024-01-23 12:28 ` Ryan Roberts
2024-01-23 12:28 ` Ryan Roberts
2024-01-23 12:28 ` Ryan Roberts
2024-01-23 12:28 ` Ryan Roberts
2024-01-22 19:41 ` [PATCH v1 10/11] mm/memory: ignore dirty/accessed/soft-dirty bits in folio_pte_batch() David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-22 19:41 ` David Hildenbrand
2024-01-23 12:25 ` Ryan Roberts
2024-01-23 12:25 ` Ryan Roberts
2024-01-23 12:25 ` Ryan Roberts
2024-01-23 12:25 ` Ryan Roberts
2024-01-23 13:06 ` David Hildenbrand
2024-01-23 13:06 ` David Hildenbrand
2024-01-23 13:06 ` David Hildenbrand
2024-01-23 13:06 ` David Hildenbrand
2024-01-23 13:42 ` Ryan Roberts
2024-01-23 13:42 ` Ryan Roberts
2024-01-23 13:42 ` Ryan Roberts
2024-01-23 13:42 ` Ryan Roberts
2024-01-23 13:55 ` David Hildenbrand
2024-01-23 13:55 ` David Hildenbrand
2024-01-23 13:55 ` David Hildenbrand
2024-01-23 13:55 ` David Hildenbrand
2024-01-23 14:13 ` David Hildenbrand
2024-01-23 14:13 ` David Hildenbrand
2024-01-23 14:13 ` David Hildenbrand
2024-01-23 14:13 ` David Hildenbrand
2024-01-23 14:27 ` Ryan Roberts
2024-01-23 14:27 ` Ryan Roberts
2024-01-23 14:27 ` Ryan Roberts
2024-01-23 14:27 ` Ryan Roberts
2024-01-22 19:42 ` [PATCH v1 11/11] mm/memory: ignore writable bit " David Hildenbrand
2024-01-22 19:42 ` David Hildenbrand
2024-01-22 19:42 ` David Hildenbrand
2024-01-22 19:42 ` David Hildenbrand
2024-01-23 12:35 ` Ryan Roberts
2024-01-23 12:35 ` Ryan Roberts
2024-01-23 12:35 ` Ryan Roberts
2024-01-23 12:35 ` Ryan Roberts
2024-01-23 19:15 ` [PATCH v1 00/11] mm/memory: optimize fork() with PTE-mapped THP Ryan Roberts
2024-01-23 19:15 ` Ryan Roberts
2024-01-23 19:15 ` Ryan Roberts
2024-01-23 19:15 ` Ryan Roberts
2024-01-23 19:33 ` David Hildenbrand
2024-01-23 19:33 ` David Hildenbrand
2024-01-23 19:33 ` David Hildenbrand
2024-01-23 19:33 ` David Hildenbrand
2024-01-23 19:43 ` Ryan Roberts
2024-01-23 19:43 ` Ryan Roberts
2024-01-23 19:43 ` Ryan Roberts
2024-01-23 19:43 ` Ryan Roberts
2024-01-23 20:14 ` David Hildenbrand
2024-01-23 20:14 ` David Hildenbrand
2024-01-23 20:14 ` David Hildenbrand
2024-01-23 20:14 ` David Hildenbrand
2024-01-23 20:43 ` Ryan Roberts
2024-01-23 20:43 ` Ryan Roberts
2024-01-23 20:43 ` Ryan Roberts
2024-01-23 20:43 ` Ryan Roberts
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=8734unqo80.fsf@kernel.org \
--to=aneesh.kumar@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=aou@eecs.berkeley.edu \
--cc=borntraeger@linux.ibm.com \
--cc=catalin.marinas@arm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=davem@davemloft.net \
--cc=david@redhat.com \
--cc=dinguyen@kernel.org \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=naveen.n.rao@linux.ibm.com \
--cc=npiggin@gmail.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=ryan.roberts@arm.com \
--cc=sparclinux@vger.kernel.org \
--cc=svens@linux.ibm.com \
--cc=will@kernel.org \
--cc=willy@infradead.org \
/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.