From: Aneesh Kumar K V <aneesh.kumar@linux.ibm.com>
To: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com>,
linux-mm@kvack.org, akpm@linux-foundation.org,
mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org,
npiggin@gmail.com, christophe.leroy@csgroup.eu
Cc: Oscar Salvador <osalvador@suse.de>,
Mike Kravetz <mike.kravetz@oracle.com>,
Dan Williams <dan.j.williams@intel.com>,
Joao Martins <joao.m.martins@oracle.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Muchun Song <muchun.song@linux.dev>,
Will Deacon <will@kernel.org>
Subject: Re: [PATCH v2 14/16] powerpc/book3s64/vmemmap: Switch radix to use a different vmemmap handling function
Date: Wed, 28 Jun 2023 09:07:36 +0530 [thread overview]
Message-ID: <4c6486bb-b81e-b9ac-7728-e8e040b3163f@linux.ibm.com> (raw)
In-Reply-To: <87r0pwnzg0.fsf@doe.com>
On 6/28/23 7:03 AM, Ritesh Harjani (IBM) wrote:
> "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
....
>> +int __meminit vmemmap_check_pmd(pmd_t *pmd, int node,
>> + unsigned long addr, unsigned long next)
>> +{
>> + int large = pmd_large(*pmd);
>> +
>> + if (pmd_large(*pmd))
>
> we already got the value of pmd_large into "large" variable.
> we can use just if (large) right?
>
>> + vmemmap_verify((pte_t *)pmd, node, addr, next);
>
> maybe we can use pmdp_ptep() function here which we used in the 1st patch?
> also shouldn't this be pmdp in the function argument instead of pmd?
>
updated
>> +
>> + return large;
>> +}
>> +
>> +void __meminit vmemmap_set_pmd(pmd_t *pmdp, void *p, int node,
>> + unsigned long addr, unsigned long next)
>> +{
>> + pte_t entry;
>> + pte_t *ptep = pmdp_ptep(pmdp);
>> +
>> + VM_BUG_ON(!IS_ALIGNED(addr, PMD_SIZE));
>> + entry = pfn_pte(__pa(p) >> PAGE_SHIFT, PAGE_KERNEL);
>> + set_pte_at(&init_mm, addr, ptep, entry);
>> + asm volatile("ptesync": : :"memory");
>> +
>> + vmemmap_verify(ptep, node, addr, next);
>> +}
>> +
>> +static pte_t * __meminit radix__vmemmap_pte_populate(pmd_t *pmd, unsigned long addr, int node,
>> + struct vmem_altmap *altmap,
>> + struct page *reuse)
>> +{
>> + pte_t *pte = pte_offset_kernel(pmd, addr);
>> +
>> + if (pte_none(*pte)) {
>> + pte_t entry;
>> + void *p;
>> +
>> + if (!reuse) {
>> + /*
>> + * make sure we don't create altmap mappings
>> + * covering things outside the device.
>> + */
>> + if (altmap && altmap_cross_boundary(altmap, addr, PAGE_SIZE))
>> + altmap = NULL;
>> +
>> + p = vmemmap_alloc_block_buf(PAGE_SIZE, node, altmap);
>> + if (!p) {
>> + if (altmap)
>> + p = vmemmap_alloc_block_buf(PAGE_SIZE, node, NULL);
>> + if (!p)
>> + return NULL;
>> + }
>
> Above if conditions are quite confusing when looking for the 1st time?
> Can we do this? Did I get it right?
>
> if (!p && altmap)
> p = vmemmap_alloc_block_buf(PAGE_SIZE, node, NULL);
>
> if (!p)
> return NULL;
>
updated
-aneesh
WARNING: multiple messages have this Message-ID (diff)
From: Aneesh Kumar K V <aneesh.kumar@linux.ibm.com>
To: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com>,
linux-mm@kvack.org, akpm@linux-foundation.org,
mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org,
npiggin@gmail.com, christophe.leroy@csgroup.eu
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Muchun Song <muchun.song@linux.dev>,
Dan Williams <dan.j.williams@intel.com>,
Oscar Salvador <osalvador@suse.de>, Will Deacon <will@kernel.org>,
Joao Martins <joao.m.martins@oracle.com>,
Mike Kravetz <mike.kravetz@oracle.com>
Subject: Re: [PATCH v2 14/16] powerpc/book3s64/vmemmap: Switch radix to use a different vmemmap handling function
Date: Wed, 28 Jun 2023 09:07:36 +0530 [thread overview]
Message-ID: <4c6486bb-b81e-b9ac-7728-e8e040b3163f@linux.ibm.com> (raw)
In-Reply-To: <87r0pwnzg0.fsf@doe.com>
On 6/28/23 7:03 AM, Ritesh Harjani (IBM) wrote:
> "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
....
>> +int __meminit vmemmap_check_pmd(pmd_t *pmd, int node,
>> + unsigned long addr, unsigned long next)
>> +{
>> + int large = pmd_large(*pmd);
>> +
>> + if (pmd_large(*pmd))
>
> we already got the value of pmd_large into "large" variable.
> we can use just if (large) right?
>
>> + vmemmap_verify((pte_t *)pmd, node, addr, next);
>
> maybe we can use pmdp_ptep() function here which we used in the 1st patch?
> also shouldn't this be pmdp in the function argument instead of pmd?
>
updated
>> +
>> + return large;
>> +}
>> +
>> +void __meminit vmemmap_set_pmd(pmd_t *pmdp, void *p, int node,
>> + unsigned long addr, unsigned long next)
>> +{
>> + pte_t entry;
>> + pte_t *ptep = pmdp_ptep(pmdp);
>> +
>> + VM_BUG_ON(!IS_ALIGNED(addr, PMD_SIZE));
>> + entry = pfn_pte(__pa(p) >> PAGE_SHIFT, PAGE_KERNEL);
>> + set_pte_at(&init_mm, addr, ptep, entry);
>> + asm volatile("ptesync": : :"memory");
>> +
>> + vmemmap_verify(ptep, node, addr, next);
>> +}
>> +
>> +static pte_t * __meminit radix__vmemmap_pte_populate(pmd_t *pmd, unsigned long addr, int node,
>> + struct vmem_altmap *altmap,
>> + struct page *reuse)
>> +{
>> + pte_t *pte = pte_offset_kernel(pmd, addr);
>> +
>> + if (pte_none(*pte)) {
>> + pte_t entry;
>> + void *p;
>> +
>> + if (!reuse) {
>> + /*
>> + * make sure we don't create altmap mappings
>> + * covering things outside the device.
>> + */
>> + if (altmap && altmap_cross_boundary(altmap, addr, PAGE_SIZE))
>> + altmap = NULL;
>> +
>> + p = vmemmap_alloc_block_buf(PAGE_SIZE, node, altmap);
>> + if (!p) {
>> + if (altmap)
>> + p = vmemmap_alloc_block_buf(PAGE_SIZE, node, NULL);
>> + if (!p)
>> + return NULL;
>> + }
>
> Above if conditions are quite confusing when looking for the 1st time?
> Can we do this? Did I get it right?
>
> if (!p && altmap)
> p = vmemmap_alloc_block_buf(PAGE_SIZE, node, NULL);
>
> if (!p)
> return NULL;
>
updated
-aneesh
next prev parent reply other threads:[~2023-06-28 3:38 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-16 11:08 [PATCH v2 00/16] Add support for DAX vmemmap optimization for ppc64 Aneesh Kumar K.V
2023-06-16 11:08 ` Aneesh Kumar K.V
2023-06-16 11:08 ` [PATCH v2 01/16] powerpc/mm/book3s64: Use pmdp_ptep helper instead of typecasting Aneesh Kumar K.V
2023-06-16 11:08 ` Aneesh Kumar K.V
2023-06-16 11:08 ` [PATCH v2 02/16] powerpc/book3s64/mm: mmu_vmemmap_psize is used by radix Aneesh Kumar K.V
2023-06-16 11:08 ` Aneesh Kumar K.V
2023-06-16 11:08 ` [PATCH v2 03/16] powerpc/book3s64/mm: Fix DirectMap stats in /proc/meminfo Aneesh Kumar K.V
2023-06-16 11:08 ` Aneesh Kumar K.V
2023-06-16 11:08 ` [PATCH v2 04/16] powerpc/book3s64/mm: Use PAGE_KERNEL instead of opencoding Aneesh Kumar K.V
2023-06-16 11:08 ` Aneesh Kumar K.V
2023-06-16 11:08 ` [PATCH v2 05/16] powerpc/mm/dax: Fix the condition when checking if altmap vmemap can cross-boundary Aneesh Kumar K.V
2023-06-16 11:08 ` Aneesh Kumar K.V
2023-06-16 11:08 ` [PATCH v2 06/16] mm/hugepage pud: Allow arch-specific helper function to check huge page pud support Aneesh Kumar K.V
2023-06-16 11:08 ` Aneesh Kumar K.V
2023-06-16 11:08 ` [PATCH v2 07/16] mm: Change pudp_huge_get_and_clear_full take vm_area_struct as arg Aneesh Kumar K.V
2023-06-16 11:08 ` Aneesh Kumar K.V
2023-06-16 11:08 ` [PATCH v2 08/16] mm/vmemmap: Improve vmemmap_can_optimize and allow architectures to override Aneesh Kumar K.V
2023-06-16 11:08 ` Aneesh Kumar K.V
2023-06-20 11:53 ` Joao Martins
2023-06-20 11:53 ` Joao Martins
2023-06-20 14:29 ` Aneesh Kumar K.V
2023-06-20 14:29 ` Aneesh Kumar K.V
2023-06-16 11:08 ` [PATCH v2 09/16] mm/vmemmap: Allow architectures to override how vmemmap optimization works Aneesh Kumar K.V
2023-06-16 11:08 ` Aneesh Kumar K.V
2023-06-16 11:08 ` [PATCH v2 10/16] mm: Add __HAVE_ARCH_PUD_SAME similar to __HAVE_ARCH_P4D_SAME Aneesh Kumar K.V
2023-06-16 11:08 ` Aneesh Kumar K.V
2023-06-16 11:08 ` [PATCH v2 11/16] mm/huge pud: Use transparent huge pud helpers only with CONFIG_TRANSPARENT_HUGEPAGE Aneesh Kumar K.V
2023-06-16 11:08 ` Aneesh Kumar K.V
2023-06-16 11:08 ` [PATCH v2 12/16] mm/vmemmap optimization: Split hugetlb and devdax vmemmap optimization Aneesh Kumar K.V
2023-06-16 11:08 ` Aneesh Kumar K.V
2023-06-28 1:09 ` Ritesh Harjani
2023-06-28 1:09 ` Ritesh Harjani
2023-06-28 3:01 ` Aneesh Kumar K V
2023-06-28 3:01 ` Aneesh Kumar K V
2023-06-16 11:08 ` [PATCH v2 13/16] powerpc/book3s64/mm: Enable transparent pud hugepage Aneesh Kumar K.V
2023-06-16 11:08 ` Aneesh Kumar K.V
2023-06-28 1:23 ` Ritesh Harjani
2023-06-28 1:23 ` Ritesh Harjani
2023-06-28 3:32 ` Aneesh Kumar K V
2023-06-28 3:32 ` Aneesh Kumar K V
2023-06-16 11:08 ` [PATCH v2 14/16] powerpc/book3s64/vmemmap: Switch radix to use a different vmemmap handling function Aneesh Kumar K.V
2023-06-16 11:08 ` Aneesh Kumar K.V
2023-06-28 1:33 ` Ritesh Harjani
2023-06-28 1:33 ` Ritesh Harjani
2023-06-28 3:37 ` Aneesh Kumar K V [this message]
2023-06-28 3:37 ` Aneesh Kumar K V
2023-06-16 11:08 ` [PATCH v2 15/16] powerpc/book3s64/radix: Add support for vmemmap optimization for radix Aneesh Kumar K.V
2023-06-16 11:08 ` Aneesh Kumar K.V
2023-06-16 11:08 ` [PATCH v2 16/16] powerpc/book3s64/radix: Remove mmu_vmemmap_psize Aneesh Kumar K.V
2023-06-16 11:08 ` Aneesh Kumar K.V
2023-06-18 11:54 ` [PATCH v2 00/16] Add support for DAX vmemmap optimization for ppc64 Sachin Sant
2023-06-18 11:54 ` Sachin Sant
2023-06-24 14:52 ` Aneesh Kumar K.V
2023-06-24 14:52 ` Aneesh Kumar K.V
2023-06-24 17:22 ` Andrew Morton
2023-06-24 17:22 ` Andrew Morton
2023-07-03 5:26 ` (subset) " Michael Ellerman
2023-07-03 5:26 ` Michael Ellerman
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=4c6486bb-b81e-b9ac-7728-e8e040b3163f@linux.ibm.com \
--to=aneesh.kumar@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=dan.j.williams@intel.com \
--cc=joao.m.martins@oracle.com \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mike.kravetz@oracle.com \
--cc=mpe@ellerman.id.au \
--cc=muchun.song@linux.dev \
--cc=npiggin@gmail.com \
--cc=osalvador@suse.de \
--cc=ritesh.list@gmail.com \
--cc=will@kernel.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.