Newsgroups: comp.sys.hp

Measuring availalble [or used] swap space programmatically was a
problem that gave me quite a headache earlier this year.  I finally
came up with a solution that worked ok and was able to verify it.

NOTE: this is not an official response from HP.  I really don't
know anything about this stuff, except what I've experienced.

Ideally, you should add up some numbers you extract from kernel
memory, but it's not possible to figure out what numbers (etc)
without having some intimate knowledge of the virtual memory system
in HPUX (for a particular REV of HPUX).  Believe me, I tried all
sorts of things.  Nobody would 'fess up to knowing anything about
how virtual memory worked -- and I couldn't get any "internal"
documentation that described it.  So I gave up on that approach
and sought an alternative method.

My idea was to use sbrk(2) and brk(2) to do a binary search on
available virtual memory.  So I wrote a program to do this.  It
would quickly find the amount of available virtual memory [within
a page].  It was not very difficult to implement.

However, there is at least one problem:  maxdsiz.  The measuring
process could not possibly grab more than the amount of memory
specified by this kernel parameter.  So, I figured I would expand
the process to be recursive -- each recursively-forked generation
would grab all the available virtual memory and communicate that
back to the parent generation.  Something like that.  Well, sometimes
that worked, sometimes it didn't.  There seemed to be a strange
timing problem that I couldn't track down -- so I finally gave up.
My final solution was to use the binary brk(2) search with a single
process, but make sure maxdsiz was set to be higher than the total
amount of swap space.

Another potentially-serious problem with this method is that any
other process that needs to allocate more dynamic storage may do
so just as the measurement is being made -- causing it to fail.  I
tried to avoid this by [programmatically] stopping any such processes
while the taking the measurement.  This didn't work since some of
those processes would abort upon being restarted (they were stupid).
So instead I just had the measurement program run with maximum
priority (required setuid root) to decrease the chance of a collision.
Seemed to work fine.

Along the way, I picked up a program that looks at kernel memory and
does some non-trivial things to get a very good estimate of swap space
usage.  It served to confirm that the numbers I was getting from my
binary search were in the right ballpark (there may have been a few
pages difference in measurements -- an insignificant amount).  But
unfortunately, this program was only a hack-in-progress, and I was
told that it must not be distributed.  Looking in kernel memory is
dependent on the OS revision, as well.  So don't ask me to post or
email the source for that program, as I won't be able to do that.

As for the binary search using sbrk(2) and brk(2), it is straightforward
enough that you should be able to implement it yourself.  My version is
quite convoluted since it tries to do that recursive-forking thing
(unless a certain option is given), so I wouldn't want to make it public.

By the way, HP has a product called "GlancePlus" that does various sorts
of system measurements (a superset of the old "monitor" functionality;
more accurate swap measurements).  It might provide a way to get
*programmatic* measurements of swap usage/availability.  I don't know;
check it out.
--
Keith Blackwell		keith_blackwell@lvld.hp.com	(not an official stmt)