maxtsiz_64bit out of range?

[Alex Lavrov.]

Hello,
trying to modify dynamic kernel parameter "maxtsiz_64bit":
kmtune -u -s maxtsiz_64bit=4398046511103

According to the manual, 4398046511103 is the maximum value. For some undefined reason I get an error "out of range". Weird, it's 64bit OS, 11.11. I set it to ~3GB and it was ok, but ti refuses to set 4398046511103.

Any thoughts about it?


thanx.

[Biswajit Tripathy]

I just tried to set maxtsiz_64bit to 4398046511103
and then to 0x3FFFFFFFFFF on my rx5670 ia64 box
(HP-UX 11i, v2) and it accepted the values without
any problem.

- Biswajit

[Alex Lavrov.]

Yea, I know, it works on other boxes. Not on this one.

[Joe Harrison_1]

Do you have 4G?

[Alex Lavrov.]

Sure, it's a V class machine with 20 CPUs

[Don Morris_1 · Accepted solution]

Ah... took me a little bit to find this.

Ok - maxtsiz / maxtsiz_64bit are dynamic in 11.11. The dynamic tunable infrastructure at the time allows the handler to be invoked at boot to intialize the tunable usage within the kernel -- and to set the expected allowed range (min / max). For maxtsiz_64bit, since the actual usage inside the kernel is a page count, not a byte count -- the maximum value allowed is set to (4Tb - system_page_size), since the highest allowed limit is to allow the page *before* the architectural limit of 4Tb.

The system.space.h file (which is what the kernel configuration uses, what SAM checks... and what the man page is based on) prints the byte value - but the kernel handler actually expects a maximum of 0x3fffffff000 or less,
since that's what the kernel would actually use.

On 11i v2 and higher, the check is made with the correct byte value, but that's then truncated inside the kernel anyway to the page count. If you do a getrlimit() you'll only see system-page-aligned values since the kernel doesn't have a mechanism to only provide half of a page in the first place.

I've filed an issue to address this - please feel free to log the issue with your support contact as well so that they can raise awareness of the issue if needed.

[Patrick Wallek]

4,398,046,511,103 = 4 TB
No, NOT 4GB, 4TB.

Unless you really need maxtsiz_64 at 4 TB, I wouldn't worry a whole lot.

[Alex Lavrov.]

After a further check, I found that there is a mistake in the documentation (?).

In the documentation it's said:
Maximum: 4398046511103 (approx 4 Gbytes)

And in SAM's help:
Maximum: 4398046507008 (approx 4 Tbytes)

4398046511103 from the documentation is no way 4G and it's outof range, but 4398046507008 (from SAM's help) is indeed 4T and it works with kmtune command.

I took the documentation from:
http://docs.hp.com/en/939/KCParms/KCparam.MaxTsiz.html


Any comments about it?

[Bill Hassell]

The maximum size for maxtsiz is academic since no (normal) process can ever reach these massize numbers. maxtsiz and maxtsiz_64 refer to the text area, the quadrant that contains unchanging executable instructions. Since there is no data in this area, it may be shared with other copies of the same process. The actual size of the text area for a process is almost the same size as the executable. The reason is that the compiler creates mostly CPU instructions inside the executable. So to create an excutable that even comes close to a maxtsiz_64 = 4Gb would require a program with BILLIONS of instructions with an executable that is more than 4Gb in size.

Most requests to increase the max-siz variables are due to "out of memory" or errno 2 (ENOMEM) which has nothing to do with the text area. To see exactly what an executable requires for the test area, use the size command on your problem program:

size /usr/local/bin/big_prog

You'll likely see just a few megs are neeeded. Making maxtsiz very large does not hurt anything, just as making maxssiz large won't hurt anything. The likelyhood that a program needs several Gb for a stack is very low. Most memory problems are related to bad error messages from programs (not identifying whether the RAM problem is stack, local data or shared memory.

I have attached an ultra-simple program that can be compiled 5 different ways (same code) and it will request local data until the opsystem says no. Compiled as a 32bit program, it will hit limits at 900, 1700, 2700 and 3700 megs. As a 64bit program, I have seen it request (successfully) 42Gb of local RAM on a 4Gb system! Compiled as a 64bit executable, it is limited only by swap space, ulimit and maxdsiz_64.