From: Claudio Jeker <cjeker@diehard.n-r-g.com>
Subject: Re: alpha: bump MAXDSIZ
To: Martijn van Duren <openbsd+tech@list.imperialat.at>
Cc: tech@openbsd.org
Date: Mon, 19 Oct 2026 10:10:17 +0200

On Mon, Oct 19, 2026 at 09:44:57AM +0200, Martijn van Duren wrote:
> On 10/19/26 09:38, Claudio Jeker wrote:
> > On Mon, Oct 19, 2026 at 09:26:39AM +0200, Martijn van Duren wrote:
> >> Hello tech@,
> >>
> >> Playing around with my alpha systems again I managed to build gcc-16 on
> >> there. During linking I found memory usage of at least 1340MB, which is
> >> larger than the curren MAXDSIZ. Diff below seems like a reasonable value
> >> to me.
> >>
> >> OK?
> >>
> >> martijn@
> >>
> >> diff /usr/src
> >> path + /usr/src
> >> commit - fa70b583ed3ab626378c9fb03bb92e8565fefa61
> >> blob - 2f095fcc79fbb92042ab91653c6e9c26d813fbc0
> >> file + sys/arch/alpha/include/vmparam.h
> >> --- sys/arch/alpha/include/vmparam.h
> >> +++ sys/arch/alpha/include/vmparam.h
> >> @@ -58,7 +58,7 @@
> >>  #define	DFLDSIZ		(128*1024*1024)		/* initial data size */
> >>  #endif
> >>  #ifndef MAXDSIZ
> >> -#define	MAXDSIZ		(1*1024*1024*1024)	/* max data size */
> >> +#define	MAXDSIZ		((paddr_t)2*1024*1024*1024)	/* max data size */
> >>  #endif
> >>  #ifndef BRKSIZ
> >>  #define	BRKSIZ		MAXDSIZ			/* heap gap size */
> >  
> > Should this be more? Now I guess it is hard to get alphas with a lot of
> > memory but it should be possible to have more then 2GB of it.
> 
> I'm not opposed to bumping it even more, I choose a relatively
> conservative value, and my machines have only 1GB max, so it was already
> hitting swap hard. Do you have a more generous number in mind?> 

I was thinking 8GB. The thing to consider is that this increases the
useable address range and with that the pmap pressure.

I think the alpha uses a 10/10/10 L1/2/3 split and 8k pages so using 8GB
would fully fill a L2 table.

While systems with more then 4GB of RAM were available I doubt anyone has
one of those.

> > Also there is some inconsitency with the form for MAXDSIZ.
> > Some archs use UL on the first number which I personally prefer over the
> > (paddr_t) typecast.
> > 
> I picked the paddr_t form from amd64. I have no opinion for one form
> over the other.

This is mostly a cleanup task to unify the defines to a single common
form and should be done as a seperate step.

-- 
:wq Claudio