linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@kernel.org>
To: Stefan Agner <stefan@agner.ch>
Cc: Mike Rapoport <rppt@kernel.org>, Minchan Kim <minchan@kernel.org>,
	ngupta@vflare.org,
	 Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	 Andrew Morton <akpm@linux-foundation.org>,
	sjenning@linux.vnet.ibm.com,  gregkh <gregkh@linuxfoundation.org>,
	Arnd Bergmann <arnd@arndb.de>,  Linux-MM <linux-mm@kvack.org>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	 Russell King - ARM Linux <linux@armlinux.org.uk>
Subject: Re: [PATCH] mm/zsmalloc: include sparsemem.h for MAX_PHYSMEM_BITS
Date: Tue, 10 Nov 2020 16:19:30 +0100	[thread overview]
Message-ID: <CAK8P3a1JEthD7j0qM05Vm94OpbTFqi_7+pe7LKX7eaANES7i+g@mail.gmail.com> (raw)
In-Reply-To: <48fdc3631bc74dd77fea1a30085c8af9@agner.ch>

On Tue, Nov 10, 2020 at 1:24 PM Stefan Agner <stefan@agner.ch> wrote:
> On 2020-11-10 12:21, Arnd Bergmann wrote:
> > Good idea. I wonder what other architectures need the same though.
>
> >> That's what x86 does:
> >>
> >> $ git grep -w MAX_POSSIBLE_PHYSMEM_BITS arch/
> >> arch/x86/include/asm/pgtable-3level_types.h:#define MAX_POSSIBLE_PHYSMEM_BITS   36
> >
> > Doesn't x86 also support a 40-bit addressing mode? I suppose
> > those machines that actually used it are long gone.
> >
> >> arch/x86/include/asm/pgtable_64_types.h:#define MAX_POSSIBLE_PHYSMEM_BITS       52
> >>
> >> It seems that actual numbers would be 36 for !LPAE and 40 for LPAE, but
> >> I'm not sure about that.
> >
> > Close enough, yes.
> >
> > The 36-bit addressing is on !LPAE is only used for early static mappings,
> > so I think we can pretend it's always 32-bit. I checked the ARMv8 reference,
> > and it says that ARMv8-Aarch32 actually supports 40 bit physical addressing
> > both with non-LPAE superpages (short descriptor format) and LPAE (long
> > descriptor format), but Linux only does 36-bit addressing on superpages
> > as specified for ARMv6/ARMv7 short descriptors.
>
> Oh so, more than 4GB of memory can be supported by !LPAE systems via
> superpages? Wasn't aware of that.

Not really, we only really use it for MMIO mappings, and only on the
Xscale3 CPU. Support for this was originally added for IXP23xx,
and the same core is present in IOP13xx and PXA3xx, but only the
last one of these is still supported in mainline, and I don't know if it
actually has anything outside of the 32-bit address space
(arch/arm/mach-pxa/include/mach/addr-map.h suggests it does not)

Russell might remember more details here, and if there is a reason
to keep IO_36 support working after we removed IXP23xx back
in 2012 and never enabled it for ARMv6 or v7. I suppose removing
it would only change a few lines in asm/domain.h, as we'd still
want to keep supersection support regardless.

> Since only ARM_LPAE selects CONFIG_PHYS_ADDR_T_64BIT it really is safe
> to assume 32 bits for non-LPAE systems.
>
> I guess that would mean adding a #define MAX_POSSIBLE_PHYSMEM_BITS 32 to
> arch/arm/include/asm/pgtable-2level.h and a MAX_POSSIBLE_PHYSMEM_BITS 40
> in arch/arm/include/asm/pgtable-3level.h. Seems straight forward and
> would solve the problem I had. I can prepare a patch for ARM, not sure
> about the other architectures...

I think I can help with that once we have agreed on a patch for ARM.

     Arnd


  reply	other threads:[~2020-11-10 15:19 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-07 15:22 Stefan Agner
2020-11-08  0:56 ` Andrew Morton
2020-11-08  1:16   ` Stefan Agner
2020-11-08  4:54     ` Florian Fainelli
2020-11-09 17:04     ` Minchan Kim
2020-11-08  6:46 ` Mike Rapoport
2020-11-10  9:29   ` Stefan Agner
2020-11-10  9:58     ` Mike Rapoport
2020-11-10 11:21       ` Arnd Bergmann
2020-11-10 12:22         ` Stefan Agner
2020-11-10 15:19           ` Arnd Bergmann [this message]
2020-11-10 16:21         ` Mike Rapoport
2020-11-10 23:36           ` Minchan Kim
2020-11-11  6:52             ` Mike Rapoport
2020-11-12 19:49               ` Minchan Kim
2020-11-11  9:33           ` Arnd Bergmann
2020-11-11 10:26             ` Mike Rapoport
2020-11-11 10:57               ` Arnd Bergmann
2020-11-11 11:04                 ` Mike Rapoport
2020-11-11 13:39                 ` Thomas Bogendoerfer
2020-11-11 14:33                   ` Arnd Bergmann
2020-11-12 19:50                     ` Minchan Kim
2020-11-12 23:46 ` Florian Fainelli

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=CAK8P3a1JEthD7j0qM05Vm94OpbTFqi_7+pe7LKX7eaANES7i+g@mail.gmail.com \
    --to=arnd@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@armlinux.org.uk \
    --cc=minchan@kernel.org \
    --cc=ngupta@vflare.org \
    --cc=rppt@kernel.org \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=sjenning@linux.vnet.ibm.com \
    --cc=stefan@agner.ch \
    --subject='Re: [PATCH] mm/zsmalloc: include sparsemem.h for MAX_PHYSMEM_BITS' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).