Memory tunables

[Don Curtis_1]

Below is a synopsis of a recent post. To reply, I receive the following errors when trying to adjust the "configurable parameters" in SAM:

"One or more tunable parameters violates an interdependency rule. SAMS expects the following statements to be true:

desfreeminfreevmebpn_sockets<=1
vmebpn_tcp_ip<=1
vmebpn_totaljobs<=8092
vmebpn_public_pages<=30

The first 2 entries no longer appear thanks to a new kernel installation (These entries are set to zero in core-hpux). The last four are found in SAM and are already true. I am running a 725/100. Any suggestions? Thanks.

Don Curtis
I have read a couple of posts concerning memory management and the "variables" LOTSFREE, DESFREE, etc. I am loading 11.0 and get an error during "configurable parameters" that include errors with these settings. My question is, how do you access/change these settings?

Thanks.


Don Morris

May 24, 2001 19:22 PM GMT [ unassigned ]

--------------------------------------------------------------------------------
LOTSFREE, DESFREE and MINFREE are tunables, so you should be able to change them with kmtune - that should be there on 11.0. Barring that, look in /usr/conf/master.d for them (should be in core-hpux), edit the file to change them and run config or mk_kernel).

Frankly, they _should_ be 0 -- that tells the kernel to just figure out good values based on available physical memory at boot.

What errors are you seeing, by the way? Something like lotsfree greater than freemem? (In other words someone just set it way too high?)

[Vincenzo Restuccia]

Hi Don for info of kernel parameters you can see http://docs.hp.com/hpux/onlinedocs/os/KCparams.OverviewAll.html

[Don Curtis_1]

That document is really only a description with min/max/default values for the parms mentioned. The parm settings I have are at the default or within the min/max. What I don't understand is why SAM reports them as an error when they obviously are not in error.

[Rita C Workman]

According to Don Morris you can edit that file to make your changes....but I 'believe' you are also asking why your getting the error since your parms are set within the min/max values. Well I found this document and basically it gives the calc for each of these values based on system,memory. Possibly even though your parm values are within min/max, they are off based on your server memory...
Doc ID#: A5598980
...."How are desfree, lotsfree, and minfree calculated?
Operating System - HP-UX
Version - 10.20
Hardware System - HP 9000
Series - E35
Solution

The following information details the significance of desfree, lotsfree, and minfree:
desfree: Amount of memory desired free, specified in pages. When the number of free pages falls below desfree, the swapper begins looking for entire processes to swap out of memory. On small-memory systems,
desfree is set to 1/16 of non-kernel memory, not to exceed 60 pages (240 KB).

minfree: Minimal amount of free memory which is tolerable, specified in pages. When the number of free pages falls below minfree, the swapper recognizes that the system is desperate for memory and attempts to swap out a process whether it is running/runnable or not
(referred to as hard swap). On small-memory systems,
minfree is set to 1/2 of desfree, not to exceed 25 pages (100 KB).

lotsfree: Plenty of free memory, specified in pages. When the number of free pages falls below lotsfree, vhand() tunes its parameters each time it is awakened. On systems with 32 MB of free memory or less after kernel initialization (referred to here as small-memory
systems), lotsfree is set to 1/8 of non-kernel memory, not to exceed 256 pages (1 MB).

Not sure if this is the answer your looking for...but it's a thought,
/rcw

[Don Curtis_1]

The DESFREE, LOTSFREE and MINFREE are "fixed", but the VME errors continue. You are right, my main question is why SAM reports the error when the values of the error items are within what SAM reports as acceptable.

For example, SAM reports, via an error message at kernel "build-time", the setting "vmebpn_sockets <= 1" must be true. This setting, shown on the same screen and during the same process that generates the error, is already set to 1, the default setting according to everything I've read. I'm not very familiar with VME. I'm not even sure I HAVE it. There are no VME or VME2 drivers loaded.

The bottom line is, I can't build a kernel.

[Rita C Workman]

Can't comment on those parms more than what I cut/pasted from looking at documentation. I'm not familiar with them myself. BUT...

Before we say you "can't" build a kernel, let me ask if you have tried to build the kernel manually. Often times SAM gets particular and will not form the kernel, but when you run through the manual steps it will build ok.
Have you tried doing it manually??

Rita

[Don Morris_1]

Unfortunately I don't know about VME tunables at all. One thought I do have, though, is to grep for the vme tunables in /usr/conf/master.d -- I know SAM gets the ranges it uses from there, so perhaps those ranges are messed up but for some odd reason SAM is getting the error messages from hard coded strings? (I know, it's a long shot -- but it's all I can think of that might help).

Best of luck....

[Don Morris_1]

Just realized that could have been more clear...

What you're looking for in this case is a line
like:

*range vmebpn_sockets<=1

in some file in that directory. In your case, since you mentioned that it _is_ 1 and SAM doesn't like it, I'd expect the range value to be <1 or something messed up like that.

Hope this helps.

[Don Curtis_1]

I checked the range values mentioned and they appear OK. I did a manual kernel build and got the following:

Loading the kernel...
/usr/ccs/bin/ld: unsatified symbols:
dfsc_link (code)
*** Error exit code 1

stop.

config: make did an exit(1)
config failure

This make any sense?

[Don Morris_1]

Unfortunately dfsc_link doesn't ring a bell with me. Anyone else out there heard of this one?

[Don Curtis_1]

Well after most of the day, and a LOT of help from fellow ITRC-ites, I got the latest SAM patch loaded. No joy. Anyone have any suggestions before a start another fresh load?

Thanks,
Don

[Steffi Jones_1]

Hello Don,

here is some info on how to regen a kernel:

check if you have a file called dfs in /usr/conf/master.d which is a leftover from 10.20 and doesn't belong on a 11.0 system.
Remove that file and then run the mk_kernel command one more time and see if you are successful then

Take care,

Steffi Jones