why is maxdsiz_64bit upper bound only 42 bits? (4 TB)

[abc_18]

According to /usr/conf/master.d/core-hpux,
the max value one can specify for maxdsiz_64bit
is 4 TB.

Here's the snippet:
*range maxdsiz<=0xfffff000 (*range maxdsiz>=256*1024
*range maxdsiz_64bit<(4*1024*1024*1024*1024 - 1024*1024*1024)
*range maxdsiz_64bit>=256*1024

Well, 4TB is only 2^42.
Yes, it's a lot.
But it's not a LOT.
And it's certainly well below 2^64.

In contrast, the 32-bit variant ("maxdsiz")
is a lot closer to 2^32.

So the question is... why is maxdsiz_64bit's
upper bound so low?

Thanks in advance.

[morganelan]

With 64-bits of address space now available, users can access:

*4.00 TB process text
*4.00 TB private data
*8.00 TB shared object space

User I/O is 1/16 of 1.00 TB and is included within the 8.00 TB of shared object space.

64-bit executables use virtual address space as follows:

*text in quad2 (address range 0x40000000 00000000 through 0x400003ff ffffffff)
*private objects (that is, data and private MMFs) in quad3 (address range 0x80000000 00000000 through 0x8000003ff ffffffff)
*shared objects (including I/O) in quads 1 and 4 (address range 0x00000000 00000000 through 0x000003ff ffffffff, and 0xc0000000 00000000 through 0xc00003ff ffffffff) with the maximum size of any single shared object being 4TB.

[Emil Velez]

The 64 bit process structure is based on a 16 TB process structure with 4 4TB quadrants. This is a design limitation.

[abc_18]

But *why* would they make the design decision to just allow 2^42 bits?

It seems like an artificially low limit...

[Alessandro Pilati · Accepted solution]

Abc,
have a look to these documents that explain the memory structure.
Anyway 2^64 bits cannot be used all as user process area. Surely the proportional dimension are not equal to the 32bits architecture.
Anyway 2^42 is quite big too!

http://www.hp.com/products1/unix/operating/infolibrary/whitepapers/aas_white_paper.pdf

http://devresource.hp.com/drc/STK/docs/refs/proc_mgt.pdf

Rgds,
Alex