pingel@wang7.UUCP (02/25/87)
How many Sys V ports cleanly deal with lack of swap space?
What is the typical method of dealing with this? Is there an
"accepted" response. Or do most systems simply terminate processes
to prevent crashing.
Example code as follows will bring out this bug. It's so simple that
anyone could produce it from scratch. Please NO FLAMES for posting
this code, as any user could code his own.
Any unprivileged user can hang SYS V.2.2 by compiling and
executing enough instances of the following simple program. This
can be achieved by continuously issue "hangu&" until the os hangs.
The operator's console will leave the following message when
this happens:
DANGER: Out of swap space
needed 30 pages.
The source of "hangu" is as follows:
/**********************************************************************
*
* Each instance of this program will require roughly 10 mega byte
* paging space.
*
* SYS V.2.2 will hang after running out of disk paging space.
*
* Allocate a large memory array and update each element.
*
*/
#define MAXSIZE 2621440
#define ITERATIONS 100
main()
{
register int inner,outer;
long array[MAXSIZE];
for (outer=0; outer < ITERATIONS; outer++) {
for (inner=0; inner<MAXSIZE; inner+=8) {
array[inner] = inner * outer;
}
}
return(0);
}
---------------------------------------------------------------------------
--
Lee Pingel, M/S 014790 harvard!vaxine!ima--+
Wang Laboratories Inc. decvax!wanginst!wang--+---wang7!pingel
1 Industrial Ave. appollo!vaxine!ima--+
Lowell, MA 01851 harvard!masscomp--+lou@hoxna.UUCP (03/03/87)
I've removed .wizards from the subject line, because I sure ain't no wizard ! > < Sys5 doesn't handle running out of swap space well. A program > that supposedly demonstrates this is provided > First of all, your program won't run on many systems, hoxna included, because that huge auto array you allocate won't fit on the stack. (We're not *all* running Amdahls, y'know). Second of all, well, you're right, "out of swap space", CRASH ! , isn't the most elegant way to handle it, but it seems to me if it happens more than more than say twice, you've got malicious users or need to re-tune your system. But the only way I can see to do things differently would be to kill the proccess asking for the fatal pages, and that could conceivably cause just as many problems. lou @ hoxna
ron@vsedev.UUCP (03/04/87)
In article <1078@hoxna.UUCP> lou@hoxna.UUCP ( L. Marco ) writes: > >> < Sys5 doesn't handle running out of swap space well. A program >> that supposedly demonstrates this is provided > > > First of all, your program won't run on many systems, >hoxna included, because that huge auto array you allocate won't fit >on the stack. (We're not *all* running Amdahls, y'know). > Well after trying to compile the er um crash program on my Sys V.2 Altos 3068, I realized that I needed to move the large array declaration out of local space and into global space, then it compiled fine. But the Altos eligantly handled the situation by returning a kernel generated error message indicating that the system was incapable of supporting the memory allocation request. So it turns out that at least this system protects itself from this type of devistation. -- ron@vsedev.VSE.COM (Ron Flax) UUCP: ..!seismo!vsedev!ron INET: vsedev.VSE.COM!ron@seismo.CSS.GOV
lou@hoxna.UUCP ( L. Marco ) (03/06/87)
In article <444@vsedev.VSE.COM>, ron@vsedev.VSE.COM (Ron Flax) writes: > [ moving the array to global will work. The Altos handles the > over-large memory request well ] Well, I tried this too, and this time when I ran a.out I got a.out: too big. Before moving the array to global space, I got a memory fault. This is an 11/780 running V.2 swapping, so maybe Sys 5 is better at this sort of thing than it seems... lou @ hoxna Guess you'd have to write a program with little arrays && run it lots of times.
mats@forbrk.UUCP (Mats Wichmann) (03/08/87)
How is it relevant that moving the array into the 'data' segment causes the kernel to be able to detect that the program is bigger than some compiled-in limit on the size of an image (or its' data segment, anyway)? That's not what the original question was. It's a little bit tricky to decide how much stack space to make available for automatic variables, especially large arrays, in a given system - because *someone* will exceed whatever limit you set and find your limit unreasonable. For example, lots of 68000 systems used to (maybe still do) settle on 32k simply because it lets you use short addressing for all "stack-relative" operations. In that case, it may have been more of a compiler-driven choice. If you don't set some sort of limit, you do get the chance for the sort of deadlock mentioned in the original article. Mats
jgs@sfmag.UUCP (03/10/87)
In System V, Release 2.1.0, we did considerable work on tightening up the paging sub-system. As a result, running out of memory resource (be it main-store or swap space) now results in errors being passed back to the running process rather than the infamous out-of-swap panic. System V, Release 3.0 was built on top of 2.1.0, and therefore will not crash when out of swap space. --Jeff Smits AT&T Information Systems 190 River Rd. Summit, NJ. 09701 (201)-522-6263 ...ihnp4!attunix!jgs
greg@osiris.UUCP (03/11/87)
There seems to be a bit of confusion with regard to this. Firstly, to the
best of my knowledge all System V.2 implementations will hang when they run out
of swap space. A rough description of how this occurs follows....
The scheduler runs
It looks around and possibly finds a process to run
It then checks the amount of free memory and decides that it must
swap a process out - calls swapout()
swapout() picks a process to swap and starts copying it to swap
but discovers that there is not enough swap space so it sleeps
until more appears.
Now if you're lucky the process picked to run may free up enough swap space
to allow swapout() to continue and everythings fine until the next
call to swapout(). However, if it doesn't free up enough space your system
is now officially hung since the scheduler is asleep in swapout() and no
longer doing its job. Which means that no more processes are scheduled
and the whole system goes idle, regardless of how many runnable processes
there are or how much physical memory is available.
This is a major problem on any machine used for software development since any
program which starts infinite recursion will eventually run out of swap space.
For example the one line program
main(){main();}
will cause the system to hang.
Allocating more swap space won't solve the problem a unless you have at least
enough swap to hold the biggest possible program (say 2 Gigabytes for a machine
with a reasonable sized virtual address space). Though this is probably
feasable, I don't want to waste that much disc space just on the off chance
that somebody might make a mistake.
The only real solution is to change the kernel so that you are guaranteed to
get more swap space and this can only really be done by killing processes.
We have made the necessary mods to the kernel we sell with our hardware and
it is virtually impossible to cause this problem on our machines. For various
complex reasons you can't always kill a process, so our kernel can be made
to hang but it requires deliberate programming effort and special circumstances.
--
Greg Kable
Osiris Technology Pty. Ltd. ACSnet: greg@osiris.oz
Unit 4 UUCP: ...!seismo!munnari!osiris.oz!greg
372 Eastern Valley Way ARPA: greg%osiris.oz@seismo.arpa
Chatswood, NSW 2067 VOICE: (02) 406 6299
Australianeighorn@qiclab.UUCP (Steven C. Neighorn) (03/17/87)
In article <306@osiris.oz> greg@osiris.oz (Greg Kable) writes: >There seems to be a bit of confusion with regard to this. Firstly, to the >best of my knowledge all System V.2 implementations will hang when they run out >of swap space. A rough description of how this occurs follows.... > > ... description of crash procedure ... Microport V/AT, a port of SYSV2 for the 80286, crashes in flames. On my 80386 running in '286 mode, I had occasion to run a couple inews programs and three batchers and an editor, and a DANGER OUT OF SWAP SPACE message appreared on the system console. The system had to be warm booted, and the associated fsck's run. I have since increased the swap space, but oh, for a real demand-paged virtual memory system, at least that would cut down on the massive swaps. Maybe someday... -- Steven C. Neighorn tektronix!{psu-cs,reed}!qiclab!neighorn Portland Public Schools "Where we train young Star Fighters to defend the (503) 249-2000 ext 337 frontier against Xur and the Ko-dan Armada" QUOTE OF THE DAY -> 'Dr. Ruth is no stranger to friction.'