On Mon, 2017-08-14 at 22:49 +1000, Michael Ellerman wrote:
> Nicholas Piggin <npig...@gmail.com> writes:
> 
> > This removes the RMA limit on powernv platform, which constrains
> > early allocations such as PACAs and stacks. There are still other
> > restrictions that must be followed, such as bolted SLB limits, but
> > real mode addressing has no constraints.

For radix, should we consider making the PACAs chip/node local ?

> > Signed-off-by: Nicholas Piggin <npig...@gmail.com>
> > ---
> >  arch/powerpc/mm/hash_utils_64.c | 24 +++++++++++++++---------
> >  arch/powerpc/mm/pgtable-radix.c | 33 +++++++++++++++++----------------
> 
> I missed that we'd duplicated this logic for radix vs hash [yes I know I
> merged the commit that did it :)]
> 
> > diff --git a/arch/powerpc/mm/pgtable-radix.c 
> > b/arch/powerpc/mm/pgtable-radix.c
> > index 671a45d86c18..61ca17d81737 100644
> > --- a/arch/powerpc/mm/pgtable-radix.c
> > +++ b/arch/powerpc/mm/pgtable-radix.c
> > @@ -598,22 +598,23 @@ void radix__setup_initial_memory_limit(phys_addr_t 
> > first_memblock_base,
> >      * physical on those processors
> >      */
> >     BUG_ON(first_memblock_base != 0);
> > -   /*
> > -    * We limit the allocation that depend on ppc64_rma_size
> > -    * to first_memblock_size. We also clamp it to 1GB to
> > -    * avoid some funky things such as RTAS bugs.
> 
> That comment about RTAS is 7 years old, and I'm pretty sure it was a
> historical note when it was written.
> 
> I'm inclined to drop it and if we discover new bugs with RTAS on Power9
> then we can always put it back.
> 
> > -    *
> > -    * On radix config we really don't have a limitation
> > -    * on real mode access. But keeping it as above works
> > -    * well enough.
> 
> Ergh.
> 
> > -    */
> > -   ppc64_rma_size = min_t(u64, first_memblock_size, 0x40000000);
> > -   /*
> > -    * Finally limit subsequent allocations. We really don't want
> > -    * to limit the memblock allocations to rma_size. FIXME!! should
> > -    * we even limit at all ?
> > -    */
> 
> So I think we should just delete this function entirely.
> 
> Any objections?
> 
> cheers

Reply via email to