Re: [PATCH v1] mips/mips_malta: Allow more than 2G RAM - Philippe Mathieu-Daudé

From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Aurelien Jarno <aurelien@aurel32.net>
Cc: Paul Burton <pburton@wavecomp.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	Yunqiang Su <ysu@wavecomp.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Jiaxun Yang <jiaxun.yang@flygoat.com>,
	Paul Burton <paul.burton@mips.com>,
	Aleksandar Markovic <amarkovic@wavecomp.com>,
	Igor Mammedov <imammedo@redhat.com>,
	Aleksandar Markovic <aleksandar.m.mail@gmail.com>
Subject: Re: [PATCH v1] mips/mips_malta: Allow more than 2G RAM
Date: Mon, 23 Mar 2020 17:41:34 +0100	[thread overview]
Message-ID: <7ec6be5f-06c8-b179-f059-1b6024d22d7f@redhat.com> (raw)
In-Reply-To: <20200323163545.GA19598@aurel32.net>

On 3/23/20 5:35 PM, Aurelien Jarno wrote:
> Hi,
> 
> Sorry for the delay, I just want to give some more details about the
> Debian.
> 
> On 2020-03-14 10:09, Philippe Mathieu-Daudé wrote:
>> IIUC today all distributions supporting MIPS ports are building their MIPS
>> packages on QEMU instances because it is faster than the native MIPS
>> hardware they have.
> 
> Actually Debian requires that packages are built on real hardware. We
> have a mix of Loongson 3 and Octeon 3 based build daemons. They all have
> 8GiB of RAM.
> 
>> Since one (or two?) years, some binaries (Linux kernel? QEMU?) are failing
>> to link because the amount of guest memory is restricted to 2GB (probably
>> advance of linker techniques, now linkers use more memory).
> 
> The problem happens with big packages (e.g. ceph which is a dependency
> of QEMU). The problem is not the physical memory issue, but the virtual
> address space, which is limited to 2GB for 32-bit processes. That's why
> we do not have the issue for the 64-bit ports.
> 
>> YunQiang, is this why you suggested this change?
>>
>> See:
>> - https://www.mail-archive.com/debian-mips@lists.debian.org/msg10912.html
>> - https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2019-January/004844.html
>>
>> I believe most of the QEMU Malta board users don't care it is a Malta board,
>> they only care it is a fast emulated MIPS machine.
>> Unfortunately it is the default board.
>>
>> However 32-bit MIPS port is being dropped on Debian:
>> https://lists.debian.org/debian-mips/2019/07/msg00010.html
> 
> The 32-bit big endian port has been dropped after the Buster (10)
> release and won't be available for the Bullseye release (11). The
> 32-bit little endian port is still available, but it's difficult to keep
> it alive given the 2GB limit.
> 
>> Maybe we can sync with the Malta users, ask them to switch to the Boston
>> machines to build 64-bit packages, then later reduce the Malta board to 1GB.
>> (The Boston board is more recent, but was not available at the time users
>> started to use QEMU to build 64-bit packages).
>>
>> Might it be easier starting introducing a malta-5.0 machine restricted to
>> 1GB?
> 
> In any case having an easy way to simulate machines with more than 2GB
> of RAM in QEMU would be great.

You mean on MIPS64, right?

I see the Boston is limited to 1/2GB, probably due to code started 
copy/pasted on the Malta. I don't know (without having to refer to 
datasheets) the maximum amount of DRAM the Boston board can handle, but 
it should be more than 2GB.

> 
> Cheers,
> Aurelien
> 