On Tue, Feb 21, 2012 at 3:45 PM, Micheal Butz <[email protected]>wrote:
> Would any know the difference between (disabled reference storage) DREF > e.g. > subpool 215 and Page fixed storage e.g. subpool 223 > > From what I understand DREF means the program is running disable for > interrupts and thus no pagIing should occur so the doc say use DREF storage > > While fixed storage means storage is fixed and the same thing applies no > paging should occur > the differences are subtle. With FIXED storage allocations, each (virtual) page is allocated to a (real) frame at the time of allocation and will remain so-paired until they are freed. If the storage is actually used then that's a good deal, however if it is one of those cases where let's say "maybe something happens and maybe it doesn't.' In that case, the fixed (real) storage would be wasted in the case where it was never referenced. That kind of thing happens often enough in real life to have warranted the creation of DREF. So DREF and FIXED are essentially the same thing (technically a form of xSQA) except for a few important differences. (1) None of the DREF pages is backed by a real frame until the page is referenced. Upon reference the page fault interrupt handler jumps in and tries to obtain a free frame from the AFQ. If it works the instruction is redriven and everyone does the happy dance. However at that point there is always the opportunity to be out of frames so there's even a special abend code to tell you that it happened. And it's transient, so you could try again and find it worked just fine. Overall this strategy means a decent probability of tying up less real storage than you would have done otherwise by using fixed storage. Win! (2) All DREF storage is above the 16MiB line just to coerce a little more modern sanity on the punters who should never be using below the line storage anyway. (3) and this is where it gets tricky... with fixed storage you can could count on the address translation staying fixed forever. However, with DREF it is only true most of the time. It is always true for DREF common storage (technically that is ESQA) however (and this bit is perhaps not widely know) it is NOT necessarily true for private area DREF (technically known as ELSQA). When an address space is logically swapped the system knows nobody is going to be "touching" the LSQA frames while the address space it toes up, so the system may play a little fast and loose. A backed LSQA page (DREF or not) will always come back in with a fixed frame backing it, but it might not be the one it logically went out with. Still following? Good. -- This email might be from the artist formerly known as CC (or not) You be the judge. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
