[RFC PATCH v0 1/1] powerpc/percpu: Use 2MB atom_size in percpu allocator on radix

[RFC PATCH v0 1/1] powerpc/percpu: Use 2MB atom_size in percpu allocator on radix

[Bharata B Rao]

The atom_size used by percpu allocator on powerpc is currently
determined by mmu_linear_psize which is initialized to 4K and
mmu_linear_psize is modified only by hash. Till now for radix
the atom_size was defaulting to PAGE_SIZE(64K). Go for 2MB
atom_size on radix if support for 2MB pages exist.

2MB atom_size on radix will allow using PMD mappings in the
vmalloc area if and when support for higher sized vmalloc
mappings is enabled for the pecpu allocator. However right now
this change will result in more number of units to be allocated
within one allocation due to increased upa(units per allocation).

Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
---
 arch/powerpc/kernel/setup_64.c | 34 +++++++++++++++++++++++++---------
 1 file changed, 25 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 1ff258f6c76c..45ce2d6e8112 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -871,6 +871,30 @@ static void __init pcpu_populate_pte(unsigned long addr)
 	      __func__, PAGE_SIZE, PAGE_SIZE, PAGE_SIZE);
 }
 
+static size_t pcpu_atom_size(void)
+{
+	size_t atom_size = PAGE_SIZE;
+
+	/*
+	 * Radix: Use PAGE_SIZE by default or 2M if available.
+	 */
+	if (radix_enabled()) {
+		if (mmu_psize_defs[MMU_PAGE_2M].shift)
+			atom_size = 1 << mmu_psize_defs[MMU_PAGE_2M].shift;
+		goto out;
+	}
+
+	/*
+	 * Hash: Linear mapping is one of 4K, 1M and 16M.  For 4K, no need
+	 * to group units.  For larger mappings, use 1M atom which
+	 * should be large enough to contain a number of units.
+	 */
+	if (mmu_linear_psize != MMU_PAGE_4K)
+		atom_size = 1 << 20;
+
+out:
+	return atom_size;
+}
 
 void __init setup_per_cpu_areas(void)
 {
@@ -880,15 +904,7 @@ void __init setup_per_cpu_areas(void)
 	unsigned int cpu;
 	int rc = -EINVAL;
 
-	/*
-	 * Linear mapping is one of 4K, 1M and 16M.  For 4K, no need
-	 * to group units.  For larger mappings, use 1M atom which
-	 * should be large enough to contain a number of units.
-	 */
-	if (mmu_linear_psize == MMU_PAGE_4K)
-		atom_size = PAGE_SIZE;
-	else
-		atom_size = 1 << 20;
+	atom_size = pcpu_atom_size();
 
 	if (pcpu_chosen_fc != PCPU_FC_PAGE) {
 		rc = pcpu_embed_first_chunk(0, dyn_size, atom_size, pcpu_cpu_distance,
-- 
2.31.1

Re: [RFC PATCH v0 1/1] powerpc/percpu: Use 2MB atom_size in percpu allocator on radix

[Nicholas Piggin]

Excerpts from Bharata B Rao's message of July 8, 2021 3:29 pm:
> The atom_size used by percpu allocator on powerpc is currently
> determined by mmu_linear_psize which is initialized to 4K and
> mmu_linear_psize is modified only by hash. Till now for radix
> the atom_size was defaulting to PAGE_SIZE(64K).

Looks like it was 1MB to me?

> Go for 2MB
> atom_size on radix if support for 2MB pages exist.
> 
> 2MB atom_size on radix will allow using PMD mappings in the
> vmalloc area if and when support for higher sized vmalloc
> mappings is enabled for the pecpu allocator. However right now

That would be nice.

> this change will result in more number of units to be allocated
> within one allocation due to increased upa(units per allocation).

In that case is there any reason to do it until then?

> 
> Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
> ---
>  arch/powerpc/kernel/setup_64.c | 34 +++++++++++++++++++++++++---------
>  1 file changed, 25 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> index 1ff258f6c76c..45ce2d6e8112 100644
> --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -871,6 +871,30 @@ static void __init pcpu_populate_pte(unsigned long addr)
>  	      __func__, PAGE_SIZE, PAGE_SIZE, PAGE_SIZE);
>  }
>  
> +static size_t pcpu_atom_size(void)
> +{
> +	size_t atom_size = PAGE_SIZE;
> +
> +	/*
> +	 * Radix: Use PAGE_SIZE by default or 2M if available.
> +	 */
> +	if (radix_enabled()) {
> +		if (mmu_psize_defs[MMU_PAGE_2M].shift)
> +			atom_size = 1 << mmu_psize_defs[MMU_PAGE_2M].shift;

Looks like this changes behaviour for radix.

Also mmu_psize_defs is a pretty horrible interface you only need it in 
some low level instruction encodings. You already explicitly know it's
2MB there, so you can just PMD_SHIFT.

If you want to know whether huge PMD is supported and enabled in vmalloc
memory, you would have to add some check which also accounts for
vmap_allow_huge, so that would be another patch.

Thanks,
Nick

> +		goto out;
> +	}
> +
> +	/*
> +	 * Hash: Linear mapping is one of 4K, 1M and 16M.  For 4K, no need
> +	 * to group units.  For larger mappings, use 1M atom which
> +	 * should be large enough to contain a number of units.
> +	 */
> +	if (mmu_linear_psize != MMU_PAGE_4K)
> +		atom_size = 1 << 20;
> +
> +out:
> +	return atom_size;
> +}
>  
>  void __init setup_per_cpu_areas(void)
>  {
> @@ -880,15 +904,7 @@ void __init setup_per_cpu_areas(void)
>  	unsigned int cpu;
>  	int rc = -EINVAL;
>  
> -	/*
> -	 * Linear mapping is one of 4K, 1M and 16M.  For 4K, no need
> -	 * to group units.  For larger mappings, use 1M atom which
> -	 * should be large enough to contain a number of units.
> -	 */
> -	if (mmu_linear_psize == MMU_PAGE_4K)
> -		atom_size = PAGE_SIZE;
> -	else
> -		atom_size = 1 << 20;
> +	atom_size = pcpu_atom_size();
>  
>  	if (pcpu_chosen_fc != PCPU_FC_PAGE) {
>  		rc = pcpu_embed_first_chunk(0, dyn_size, atom_size, pcpu_cpu_distance,
> -- 
> 2.31.1
> 
> 

Re: [RFC PATCH v0 1/1] powerpc/percpu: Use 2MB atom_size in percpu allocator on radix

[Bharata B Rao]

On Mon, Jul 12, 2021 at 01:00:10PM +1000, Nicholas Piggin wrote:
> Excerpts from Bharata B Rao's message of July 8, 2021 3:29 pm:
> > The atom_size used by percpu allocator on powerpc is currently
> > determined by mmu_linear_psize which is initialized to 4K and
> > mmu_linear_psize is modified only by hash. Till now for radix
> > the atom_size was defaulting to PAGE_SIZE(64K).
> 
> Looks like it was 1MB to me?

Was it hash? Because atom_size will get set to 1MB on hash.
And both on baremetal and KVM radix, I see 64K atom_size.

> 
> > Go for 2MB
> > atom_size on radix if support for 2MB pages exist.
> > 
> > 2MB atom_size on radix will allow using PMD mappings in the
> > vmalloc area if and when support for higher sized vmalloc
> > mappings is enabled for the pecpu allocator. However right now
> 
> That would be nice.
> 
> > this change will result in more number of units to be allocated
> > within one allocation due to increased upa(units per allocation).
> 
> In that case is there any reason to do it until then?

Not strictly. I observed a similar setting on x86 which has
been there for long, so was just checking if it makes sense
here too.

> 
> > 
> > Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
> > ---
> >  arch/powerpc/kernel/setup_64.c | 34 +++++++++++++++++++++++++---------
> >  1 file changed, 25 insertions(+), 9 deletions(-)
> > 
> > diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> > index 1ff258f6c76c..45ce2d6e8112 100644
> > --- a/arch/powerpc/kernel/setup_64.c
> > +++ b/arch/powerpc/kernel/setup_64.c
> > @@ -871,6 +871,30 @@ static void __init pcpu_populate_pte(unsigned long addr)
> >  	      __func__, PAGE_SIZE, PAGE_SIZE, PAGE_SIZE);
> >  }
> >  
> > +static size_t pcpu_atom_size(void)
> > +{
> > +	size_t atom_size = PAGE_SIZE;
> > +
> > +	/*
> > +	 * Radix: Use PAGE_SIZE by default or 2M if available.
> > +	 */
> > +	if (radix_enabled()) {
> > +		if (mmu_psize_defs[MMU_PAGE_2M].shift)
> > +			atom_size = 1 << mmu_psize_defs[MMU_PAGE_2M].shift;
> 
> Looks like this changes behaviour for radix.

Yes, it does as it increases the atom_size which results in higher
upa as noted. Did you mean some other behaviour change?

> 
> Also mmu_psize_defs is a pretty horrible interface you only need it in 
> some low level instruction encodings. You already explicitly know it's
> 2MB there, so you can just PMD_SHIFT.

Ok.

> 
> If you want to know whether huge PMD is supported and enabled in vmalloc
> memory, you would have to add some check which also accounts for
> vmap_allow_huge, so that would be another patch.

Yes makes sense if we want to tie the setting of higher atom_size
to actual availability of PMD mappings in vmalloc.

Regards,
Bharata.