mark@zok.UUCP (Mark W. Snitily) (09/25/90)
In article <9009041636.AA23617@hansen.com> jim@ncd.COM (Jim Fulton) writes: > > When I move the > mouse pointer from an active xterm window to one of the swapped-out > windows and start typing, input goes to the window that I WAS on until > the new window comes in from disk. > >The problem is that the window manager is swapped out, not the xterm. So, >it takes it a while to wake up and refocus on the new window. One way to >avoid this is to put NoTitleFocus in your .twmrc, although it means that >key strokes in the title bar will be sent to the application with SendEvent >rather than being delivered "normally". Having seen this query (with the same answer) a number of times, I'm surprised the suggestion of turning the window manager's "sticky" bit on hasn't been mentioned. Assuming you're using twm, you own it, and you're in the directory where it resides, then chmod 1755 twm with set the sticky bit on. Quoting from the man page: "If an executable file is set up for sharing (this is the default) then mode 01000 (save text image after execution) prevents the system from abandoning the swap-space image of the program-text portion of the file when its last user ter- minates." In other words, it won't get swapped out. The con is that it'll always be there, but you'd probably want to keep the window manager in memory anyway. -- Mark Mark W. Snitily Consulting Services: 894 Brookgrove Lane Graphics, Operating Systems, Compilers Cupertino, CA 95014 (408) 252-0456 mark@zok.uucp West Coast UUCP X11 archive site If your mailer doesn't like the .uucp domain, these also work: ...!{mips,sgi}!zok!mark, mark%zok@mips.com, mark%zok@sgi.com
peter_colby@viewlogic.COM (09/25/90)
W.R.T the "sticky bit", I'm sure I won't be the only person to say this but the sticky bit says to keep the "swap image" around when the last user exits the program. This has nothing to to with physical memory. twm will STILL GET SWAPPED OUT when the system needs memory for another process. What will happen is that when you exit from X (via killing twm usually), twm will stay in swap waiting for you to start it up again - not a very desireable outcome on a system with one display. I'm not sure but you may have to reboot the system to get a "sticky" program out of swap. Peter C
rwl@amber.cs.Virginia.EDU (Ray Lubinsky) (09/25/90)
In article <489@zok.UUCP>, mark@zok.UUCP (Mark W. Snitily) writes: : |> Quoting from the man page: |> "If an executable file is set up for sharing (this is the |> default) then mode 01000 (save text image after execution) |> prevents the system from abandoning the swap-space image of |> the program-text portion of the file when its last user ter- |> minates." |> |> In other words, it won't get swapped out. The con is that it'll always |> be there, but you'd probably want to keep the window manager in memory |> anyway. Nope. Sorry. It means that the text portion of the process will not be removed from the swap partition on the disk (not main memory) which is just what the man page says. This is only of potential advantage when you have a program like a shell (or window manager) where you'd like to avoid the overheading of finding the file on disk the next time you start it up. On a busy multiuser system, setting the sticky bit on a popular program has little affect because there's rarely a time when *someone* isn't running it. In this case the text portion of the process is always on the swap track anyway. | Ray Lubinsky rwl@uvacs.cs.Virginia.EDU (Internet) | | rwl@virginia (BITNET) | | Department of Computer Science, ...!uunet!virginia!uvacs!rwl (UUCP) | | University of Virginia (804) 982-2219 (voice) |
kaleb@thyme.jpl.nasa.gov (Kaleb Keithley ) (09/25/90)
If you have a Sun, and are using SunOS 4.1, you could add a function
call to plock(), which, according to the man page:
DESCRIPTION
plock() allows the calling process to lock its text segment
(text lock), its data segment (data lock), or both its text
and data segments (process lock) into memory. Locked seg-
ments are immune to all routine swapping.
The only drawback is that the process must have an effective user ID
of super-user to make this call.dshr@eng.sun.COM (David Rosenthal) (09/25/90)
> Quoting from the man page: > "If an executable file is set up for sharing (this is the > default) then mode 01000 (save text image after execution) > prevents the system from abandoning the swap-space image of > the program-text portion of the file when its last user ter- > minates." > > In other words, it won't get swapped out. The con is that it'll always > be there, but you'd probably want to keep the window manager in memory > anyway. > Even in old, pre-virtual-memory, Unix systems like the one you seem to have got the man page from the sticky bit had no influence on whether or not the program was swapped out while it was running. It controlled whether starting up a new version of the process could get its image from swap space or from the file system. Getting it from swap was typically faster. The con was that the image consumed swap space (not memory) all the time whether or not a process was running that image. Since the window manager is started once and runs continually, the sticky bit is irrelevant even in swap-based systems. In modern virtual-memory Unix systems the sticky bit on files typically has no effect. Swapping a process (which in this context means pushing its u-area to swap and unloading all its mappings) saves very little resource, so it isn't common. And since the image is moved to and from disk by random page faults rather than by a single contiguous I/O, there is no performance advantage to getting the image pages from swap rather than the file system. To decrease the time needed to get the window manager started, set its process priority higher (nice). This normally has no effect on the priority the system places on satisfying the winodw manager's page faults, but it will ensure that the system won't run any other process when it could be running the window manager, and thus the page faults will be detected earlier than they would otherwise be. David.
mark@zok.UUCP (Mark W. Snitily) (09/25/90)
In article <489@zok.UUCP> I wrote: [stuff about setting twm's sticky bit on] >In other words, it won't get swapped out. Opps, how embarrassing. Before there's a flood of followups please let me correct my spreading of misinformation. Setting the sticky bit will *NOT* prevent the window manager from getting swapped out. Actually what will happen is that when you exit X (or simply kill twm) twm will stay around in swap until you start it up again. Somewhat useful for applications like emacs where you terminate it and start it up a number of times, but not useful for a client like twm where it's started only once. Let me repeat, setting the sticky bit has *nothing* to do with keeping a process in physical memory. (This'll teach me not to post an article long after I should have gone to bed. :-) Thanks to everyone who quickly pointed out my erroneousness posting. Out of curiosity, on the topic of swapping, do any of the new OS's (e.g. System V Release 4, BSD 4.4, OSF 1, etc.) provide a mechanism for preventing a specified process from being swapped out? -- Mark Mark W. Snitily Consulting Services: 894 Brookgrove Lane Graphics, Operating Systems, Compilers Cupertino, CA 95014 (408) 252-0456 mark@zok.uucp West Coast UUCP X11 archive site If your mailer doesn't like the .uucp domain, these also work: ...!{mips,sgi}!zok!mark, mark%zok@mips.com, mark%zok@sgi.com
ian@hewey.UUCP (Ian Hogg) (09/26/90)
> > Out of curiosity, on the topic of swapping, do any of the new OS's > (e.g. System V Release 4, BSD 4.4, OSF 1, etc.) provide a mechanism > for preventing a specified process from being swapped out? HP has a plock system call, however, you must be superuser to use it. -- =============================================================================== Ian Hogg email: ian@dms.cdc.com Control Data Corporation phone: (612)-553-4484
grp@Unify.com (Greg Pasquariello) (09/26/90)
In article <489@zok.UUCP>, mark@zok.UUCP (Mark W. Snitily) writes: > In article <9009041636.AA23617@hansen.com> jim@ncd.COM (Jim Fulton) writes: > > > > When I move the > > mouse pointer from an active xterm window to one of the swapped-out > > windows and start typing, input goes to the window that I WAS on until > > the new window comes in from disk. > > [ Some stuff deleted...] > Having seen this query (with the same answer) a number of times, I'm > surprised the suggestion of turning the window manager's "sticky" bit on > hasn't been mentioned. > [ Some more stuff deleted...] > > Quoting from the man page: > "If an executable file is set up for sharing (this is the > default) then mode 01000 (save text image after execution) > prevents the system from abandoning the swap-space image of > the program-text portion of the file when its last user ter- > minates." > > In other words, it won't get swapped out. The con is that it'll always > be there, but you'd probably want to keep the window manager in memory > anyway. Setting the sticky bit doesn't prevent swapping. It simply saves the process image in swap space after the process terminates, so that subsequent invocations don't have to reload from scratch. > > -- Mark --- -Greg Pasquariello grp@unify.com
guy@auspex.auspex.com (Guy Harris) (09/27/90)
>Out of curiosity, on the topic of swapping, do any of the new OS's >(e.g. System V Release 4, BSD 4.4, OSF 1, etc.) provide a mechanism >for preventing a specified process from being swapped out? The "plock()" somebody mentioned in SunOS 4.1 comes from S5 (the API does, anyway), although I don't know if it prevents any of the shared libraries being used by the process from being swapped out (either on SunOS 4.1/S5R4 or on S5R3). SunOS 4.1 has "mctl()", and S5R4 has "memcntl()", to lock regions of the address space into memory; 4.4BSD and/or OSF/1 may have similar calls. All these calls, of course, require appropriate privilege (typically super-user privilege). I wouldn't necessarily be happy if somebody stuck them into a window manager....