Path: utzoo!utgpu!attcan!uunet!husc6!mailrus!ncar!oddjob!gargoyle!att!lzaz!hutch From: hutch@lzaz.ATT.COM (R.HUTCHISON) Newsgroups: comp.unix.questions Subject: Re: Sticky bit on paging systems Message-ID: <193@lzaz.ATT.COM> Date: 9 Aug 88 19:08:43 GMT References: <204@alobar.ATT.COM> Distribution: na Organization: AT&T ISL Lincroft NJ USA Lines: 40 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