Locked Memory under Guardian similar to mlock()

[Henning Horst]

Hi All,

I am wondering if there is a system call for guardian programs similar
like there is mlock() for Linux (see http://linux.die.net/man/2/mlock)
in order to prevent memory to be swapped (thus locked memory).

Thanks in advance,

Henning

[Anupam Das]

On Feb 28, 8:55 pm, Henning Horst <comf...@googlemail.com> wrote:
> Hi All,
>
> I am wondering if there is a system call for guardian programs similar

> like there is mlock() for Linux (seehttp://linux.die.net/man/2/mlock)

> in order to prevent memory to be swapped (thus locked memory).
>
> Thanks in advance,
>
> Henning

Did you mean this?

RESIDENT:

The RESIDENT attribute causes procedure code to remain in main memory
for the
duration of program execution. The operating system does not swap
pages of this
code. Binder allocates storage for resident procedures as the first
procedures in the
code space. An example is:

PROC res_proc RESIDENT;
BEGIN
!Do some work
END;

[Keith Dick]

Anupam Das wrote:
> On Feb 28, 8:55 pm, Henning Horst <comf...@googlemail.com> wrote:
>

>>Hi All,
>>
>>I am wondering if there is a system call for guardian programs similar

>>like there is mlock() for Linux (seehttp://linux.die.net/man/2/mlock)

>>in order to prevent memory to be swapped (thus locked memory).
>>
>>Thanks in advance,
>>
>>Henning
>
>

> Are you looking for RESIDENT option?

>
> RESIDENT:
>
> The RESIDENT attribute causes procedure code to remain in main memory
> for the
> duration of program execution. The operating system does not swap
> pages of this
> code. Binder allocates storage for resident procedures as the first
> procedures in the
> code space. An example is:
>
> PROC res_proc RESIDENT;
> BEGIN
> !Do some work
> END;

RESIDENT applies only to code pages, so I kind of doubt it provides what Henning is looking for. It might be a partial solution, but I imagine he needs to lock data segments, too.

I believe there are facilities available to privileged programs for locking memory (and certainly it is available within the OS), but I believe the details have not been published in user manuals. I imagine if you open a case with the customer support center and explain why you need to lock memory, they would be able to give you some documentation about it.

I imagine you could perform memory locking only in programs which have been licensed (FUP LICENSE command), but I might be wrong about that restriction.

[dimandja]

Keith,

I remember working at a shop where we had a Resident proc. This proc
also contained a huge table where the entire Pathway application had
instant access. The proc remained in what I assumed was locked memory
for the duration (24/7).

My question is, when a Resident proc allocates memory (or array),
shouldn't the data remain "locked" within it?

[Keith Dick]

If that table was in a P-relative array, it was in the code pages of the proc, and so the RESIDENT attribute would keep that table and the procedure's code in memory. As far as I know, the RESIDENT attribute has no effect on any data segment pages. If I recall correctly, there is a Guardian proc callable only by priv processes that can lock data pages into memory, but that has no connection with RESIDENT.

And that all is about the TNS architecture. I never learned how any of that carried over to the MIPS or Itanium native code, if it did. I see that RESIDENT is still documented for pTAL, so I guess the concept is still supported in the native code environments.

[Henning Horst]

Hi Anupam, Dimandja and Keith,

First thanks a lot for your prompt response.

Basically I would like to keep a big table or an array within the
memory, potentially by just marking the whole stack or heap or a
certain part as locked memory. It would be nice to call the function
from C, however if I can interface somehow to a pTAL function that
would do as well. The RESIDENT proc sounds in the right direction, the
text does not seem clear what exactly is in locked memory though.

I followed your suggestion, Keith, and opened up a case with HP. I
will let you know what I find out from them :-)

Many Regards,

Henning

[Keith Dick]

If your data is set at compile time, then RESIDENT would do the job. It only locks code pages in memory, not data pages (at least that is how it was on TNS, and the description seems the same for native mode). There is a _resident attribute for C functions available when you turn on HP extensions. It is described in the C/C++ Programmer's Guide. My quick look at it indicates it works just like RESIDENT does for TAL and pTAL.

If you need to be able to modify the data at run time, something different from RESIDENT or _resident will be needed.

[Henning Horst]

Thanks for that additional clarification, Keith, I think _resident
will then not be sufficient for this case.

There actually is an equivalent to mlock() - searching the cextdecs.h
there is a priv procedure to "lock memory" and "unlock memory".

More details on usage of those unfortunately have to be requested from
HP directly and mustn't be published.

You help and responsiveness is very much appreciated, thank you very
much !

Henning

[Keith Dick]

You're welcome. Those procedures seem to be the ones I remembered and could not find in the published manuals, which is why I suggested asking HP Support about the matter.

The fact that it is a PRIV procedure means that it can only be called by a process that runs from an object file that has been licensed or is run by SUPER.SUPER, something you don't want for a typical application program, which probably is why those procedures were removed from the public manuals. I'm not sure I agree with hiding such capabilities, but apparently HP has decided to do so. I hope they will describe to you how to use those procedures once you explain your need.

If I remember correctly, a PRIV procedure can only be called from code that is already executing in PRIV mode. To avoid making your whole program run in PRIV mode, you can write some procedures that include the _callable attribute, and use them as a wrappers around calls to the PRIV procedures. Although it seems not to be described in the C manual, the _callable attribute on a procedure causes the process to enter PRIV mode when entering the procedure and leave PRIV mode when exiting the procedure. Your program still has to be licensed (or be run by SUPER.SUPER) in order to contain CALLABLE procs, but this approach limits the time your program is running in PRIV mode to the time it actually is executing within the _callable procs, which should only be the few lines necessary to call the proc to lock or unlock the memory.

[ozbear]

If I were your systems architect or manager you'd have to have a
pretty compelling reason to do this. It is generally best to leave
memory management to the memory manager. If your system is
experiencing memory pressure severe enough to force your pages out,
even though they are being frequently accessed, then locking your
pages in is only going to make matters worse for other processes.
If your application really cannot tolerate waiting for a page-in,
then move enough other processes out of a CPU of your choice
such that they will remain "natually" resident and run your process
there.
Memory, like CPU, is a shared resource that should not monopolized.

Oz
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[MicroTech]

On Friday, March 2, 2012 5:05:47 PM UTC+8, Henning Horst wrote:

> There actually is an equivalent to mlock()

Hello Henning!

The procedures you need are [UN]LOCKMEMORY(). The RESIDENT attribute only makes sure that CODE memory is made resident.

Being PRIV procedures (not CALLABLE), the user interface for these procs is not published (and EXTDECS0/cextdecs comments (intentionally) offer no help).

You may get the internal docs for [UN]LOCKMEMORY() from HP, but I doubt it. For security reasons, using PRIV procs in user applications is not encouraged (requires the object attribute PROGID).

Tchuess,

Henry Norman
MicroTech Consulting
https://sites.google.com/site/microtechnonstop

[Keith Dick]

If an object file contains a PRIV or CALLABLE proc, either it must be licensed via the FUP LICENSE command, or it must be run by SUPER.SUPER. It might be true that being owned by SUPER.SUPER and having the PROGID attribute set is good enough, but I'm not sure of that.

[Henning Horst]

Hello Henry and Keith,

thanks much for the additional comments ! Your help is very
appreciated.

Many Regards,

Henning