[comp.unix.questions] Sticky bit on paging systems

grs@alobar.ATT.COM (Gregg Siegfried) (08/04/88)

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?

Has anyone experimented with advantages and/or disadvantages of setting the
sticky bit on fairly frequently used programs on SVR3.  Intuitively, it
would buy you nothing, were to you set it on the shell, as it is 
already in memory all the time.  But for other programs such as (the
classic) vi or emacs, it could be a win, depending on how the system
handles it.  Note that while older systems (SVR2.0) were distributed 
with vi's sticky bit set, this is not the case with SVR3.  Is this an
indication that the advent of demand paging rendered it is pseudo-obsolete?

I'm a stickler for trivia of this sort..

Please send me email concerning this, and if anyone else is
intrested, I'll summarize.

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

hutch@lzaz.ATT.COM (R.HUTCHISON) (08/10/88)

From article <204@alobar.ATT.COM>, by grs@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@alobar.att.com   | Don't Rock - Wobble
]  ARPA: grs%alobar.att.arpa  | 513-629-8314 (work) 513-561-0368 (antiwork)

Bob Hutchison
lzaz!hutch