Article 4881 of vmsnet.internals:
"David F. Wall" <wall@rndhse.enet.dec.com> sez:

>Brian Schenkenberger, VAXman- wrote:
>> 
>> If I use the $LCKPAG system service to lock a page in process address
>> space, the page is locked in physical memory and in the process work-
>> ing set.  On Alpha, does this imply that the L1,L2 and L3 page tables
>> which map this address range are lock down as well?  I am especially
>> unsure now that the page tables reside exclusively in their own page
>> table space and not in the PHD.
>> 
>> To put this another way, if viewed from another process and if I have
>> the PTVAs of the L1PTE, L2PTE and the L3PTE which map this process's
>> page, will I find the PTE(s) valid?
>> 
>> I've looked over the source listings for the $LCKPAG system service in
>> SYSLKWSET.LIS and I'm still not quite certain...
>
>The answer is yes, the page table pages are locked in memory, but not
>due to
>any explicit action of $LCKPAG.  The associated page table pages are
>implicitly also locked into memory because of what the swapper does with
>process headers (or rather, doesn't do with process headers) when there
>are
>pages locked into memory.  The removal of page tables from the process
>header
>has not changed this.
>
>The bit that signals locking to physical memory means something else
>when that
>bit is set for a page table page, and might have nothing to do with
>whether
>the mapped page is locked or not.
>

Thanks David.  I was beginning to think that was perhaps the only
one that understood this 3-tiered PT stuff.  I thought it was the 
case but just wanted to get a second opinion so I'd have that warm
and fuzzy feeling.

>This behavior is not something you could easily deduce reading
>listings.  In
>fact, this isn't written down in anything quotable in a public forum,
>which
>means 1) You're gonna sort of have to take our word for it and 2) We
>have the right to change it if we come up with a good enough reason to
>do so.

... and when that happens, I'll change my code to insure the PTs are 
faulted in before referencing them.

Thanks again for the answer.

VAXman-                                                 VAXman@TMESIS.COM