Hi Ted,
Thanks for clarifying that for me.
Is there any reason that sparc64's limit is so aggressively
conservative? With the T series machines with hundreds of gigs of ram,
an 8GB limit seems anaemic. I am baffled that my SGI box can use twice
the per-process memory than my T4 can.
Is there any particular reason for the low sparc64 MAXDSIZ? Is there any
way for this limit to be increased as I have some large data
manipulation that needs to be done and I really would love to be able to
use my OS of choice for it. It would break my heart to have to have to
use something other than OpenBSD for the task at hand simply because of
arbitrary limits. Is there some sort of security benefit to the these
low limits? I obviously understand 32 bit arches having a limitation,
but sparc64 and amd64's limit seems excessively low-- how is nobody else
banging up against these limits? I don't mean to sound like a whiner, I
am just legitimately curious as to how other folks aren't having issues
with these limitations.
On 01/30/18 18:12, Ted Unangst wrote:
Jordan Geoghegan wrote:
amd64 MAXDSIZ : ((paddr_t)32*1024*1024*1024)
i386 MAXDSIZ : (3UL*1024*1024*1024)
sparc64 MAXDSIZ : (8L*1024*1024*1024)
mips64 MAXDSIZ : 16UL*1024*1024*1024
hppa MAXDSIZ : 1*1024*1024*1024UL
arm64 MAXDSIZ : ((paddr_t)16*1024*1024*1024)
Could anyone tell me what the 'U' , "L' and '((paddr_t)' means?
Unsigned, long, and typedef for physical address. Casts to make sure the
multiplication doesn't overflow.
I hope I'm reading this wrong, but does sparc64 have an 8GB per-process
limit? I will be shocked if a mips64 box can allocate more memory
per-process than a sparc64 T-series.
The limits are somewhat conservative, and there's no particular logic to any
of them (except maybe i386, which is about as large as it can possibly be).
They're generally set to be big enough that nobody complains.
