Re: [PATCH v1] mips/mips_malta: Allow more than 2G RAM

[Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3332 bytes --]

18:38 Pon, 23.03.2020. Aurelien Jarno <aurelien@aurel32.net> је написао/ла:
>
> 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.
>

In my company, we do have both Octeon (don't know at this moment what
version) and Boston systems.

Boston seems to me as a very good candidate for enabling RAM > 2GB. I never
saw it phisically, since it is assigned to a different department, but just
anectodaly I heard that it is designed as a desktop (or even server)
machine, and, therefore, it almost certainly supports > 2GB.

Given current circumstances of remote work for most of us, and limited
movement, it may be somewhat difficult for me to access it, but it is not
imposible.

Please take everything I said in this email with a grain of salt, since it
is based more on hallway chats, rather than on facts.

I'll try to get more info, hopefully soon.

Yours,
Aleksandar


> Cheers,
> Aurelien
>
> --
> Aurelien Jarno                          GPG: 4096R/1DDD8C9B
> aurelien@aurel32.net                 http://www.aurel32.net
>

[-- Attachment #2: Type: text/html, Size: 4413 bytes --]