Sticky bit on paging systems

[R.HUTCHISON]

>From article <204 at alobar.ATT.COM>, by grs at alobar.ATT.COM (Gregg Siegfried):
] 
] Hi, all.
] I have a question (obviously .. note the newsgroup you're reading)..
] about the behavior of the sticky bit on paging systems, System V
] release 3 in particular.  The sticky bit on swapping systems maintained a 
] copy of the program text in the (contiguous) swap area, after initial 
] invocation, and release from the text table, which provided good startup 
] speed improvement.
] 
] On paging systems, presumably the treatment would have to take a different
] form.  After a program pages itself into memory, specifically the
] region table, and is released, what differs in the handling of the
] program text if the sticky bit is set?  Is it kept in the region table?
] If the system has boatloads of free memory and region table entries,
] this would make sense.  But, if memory is limited, and this was traditionally
] where the sticky bit provided performance gains on swapping systems, does
] it buy you anything?
...

My guess is that it would have something to do with an a.out mapping
table set up at exec time.  This table lists all the data blocks in
the a.out file so that during a "page in" it doesn't have to resolve
indirect addresses in the inode. I would guess that this table, along
with other inode-related table entries would remain intact and would
no have to be rebuilt (or initialized) on the next exec.  I don't
think that the OS would leave anything worthwhile on a swap
(page) device after exit - If a page is read in from an a.out and is
"stolen" before being changed it is just deallocated and read in the
next time from the a.out.

] Thanks,
] -- 
]  Gregg Siegfried            | Nothing I say should be taken as AT&T
]  AT&T - Cincinnati          | policy or opinion .. I just hack here.
]  UUCP: grs at alobar.att.com   | Don't Rock - Wobble
]  ARPA: grs%alobar.att.arpa  | 513-629-8314 (work) 513-561-0368 (antiwork)

Bob Hutchison
lzaz!hutch