Received-SPF: pass (google.com: domain of linux-kernel+bounces-95572-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-251-g8332da0bf6-fm-20240305.001-g8332da0b
Precedence: bulk
MIME-Version: 1.0
Message-Id: <fd7d8c88-5832-4179-890a-3b3af88a83a9@app.fastmail.com>
In-Reply-To: <74afd65d-85ed-4ee9-b5f2-a6702f9bc01c@gaisler.com>
References: 
 <20240224-sam-fix-sparc32-all-builds-v2-0-1f186603c5c4@ravnborg.org>
 <20240224-sam-fix-sparc32-all-builds-v2-4-1f186603c5c4@ravnborg.org>
 <8d5780f5-1047-48d7-a9c9-09b95c7b5604@gaisler.com>
 <5648dca0-4853-4dfb-91cf-282a656beb1e@app.fastmail.com>
 <bc33b608-e0b5-4dff-aa05-8513dce409b3@gaisler.com>
 <75a4a08d-85c2-4a60-9cbd-90dd50f765a8@app.fastmail.com>
 <5d97d50a-9d40-4651-8071-073dee5f9aa8@gaisler.com>
 <001ba36a-9d4c-45c4-b1f2-448824848afc@app.fastmail.com>
 <5568f26d-9e1a-4530-a086-564659b21666@app.fastmail.com>
 <74afd65d-85ed-4ee9-b5f2-a6702f9bc01c@gaisler.com>
Date: Thu, 07 Mar 2024 14:06:45 +0100
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Andreas Larsson" <andreas@gaisler.com>,
 "Sam Ravnborg" <sam@ravnborg.org>, "Maciej W. Rozycki" <macro@orcam.me.uk>,
 sparclinux@vger.kernel.org, "Randy Dunlap" <rdunlap@infradead.org>
Cc: "Miquel Raynal" <miquel.raynal@bootlin.com>,
 linux-parport@lists.infradead.org, "David S . Miller" <davem@davemloft.net>,
 linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 4/7] sparc32: Do not select ZONE_DMA
Content-Type: text/plain

On Thu, Mar 7, 2024, at 13:42, Andreas Larsson wrote:
> On 2024-03-06 19:19, Arnd Bergmann wrote:
>
>> I still don't know the history behind this choice, but I
>> see this was already configured the same when arch/sparc/
>> was originally merged. You can probably change it to a more
>> sensible 0xc0000000 or 0x80000000 like on other
>> architectures and run without highmem on anything with
>> less than 2GB of total RAM.
>> 
>> How much RAM do Leon machines have typically, or at the
>> maximum?
> The amount of RAM can vary greatly between systems, from less that
> 128 MiB up to 2 GiB. An upcoming design uses the entire 36-bit
> physical address space and have the possibility of having up to 60
> GiB memory.

If the current maximum is 2GiB, that would be easily handled
by making PAGE_OFFSET configurable the same way that x86 or
arm do, where the common CONFIG_VMSPLIT_3G would extend lowmem
from 192MiB to a little under 1GiB, with PAGE_OFFSET 0xc0000000,
and VMSPLIT_2G_OPT allows exactly 2GiB of lowmem, plus a little
under 2GiB of user addressing.

This would also be an improvement over using highmem for
most applications today, and it means you can keep using the
same setup once highmem support gets removed from the kernel.

For a new design, I would strongly advise against advertising
support for more than 2GiB on a 32-bit Linux kernel, as this
is likely to not be supportable in the future. Note that
in the best case today (40 byte struct page), the mem_map[]
array uses 10MiB of lowmem per GiB installed memory, so you
quickly run out of lowmem when you allow more RAM.

     Arnd