On 10/19/26 10:10, Claudio Jeker wrote:
> 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.
> 

Running with the diff below now. Let me reduce my gas bill by compiling
python/gdb-18.1 and I'll get back to you.

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		(8UL*1024*1024*1024)	/* max data size */
 #endif
 #ifndef BRKSIZ
 #define	BRKSIZ		MAXDSIZ			/* heap gap size */