On Wed, 15 Mar 2000, Scott Lurndal wrote:
> As a matter of fact, Unisys (nee Burroughs) mainframes have
> supported this for about forty years now. The process which
> attempts to allocate memory is suspended (and the operator
^^^^^^^^
It's not allocation. The system is out of swap. You need to write
a dirty page-frame to disk, but there no space left. It's the kernel
trying to do that, not the process.
> notified). The operator can wait for jobs to leave the mix,
> discontinue (kill) other jobs, or kill the waiting job.
If you're short of RAM, and there's swap space available, that's called
swapping, and even early UNIX systems could do that, restoring the process
automagically when enough RAM is back again. This works because, on
memory shortage, swapping a whole process out frees memory up, so the
other processes may continue running, and eventually terminate.
On swap space shortage, stopping a process won't free any swap space up.
The only way to solve swap shortage is adding more space, or killing
processes. Both have disadvantages (if done automatically).
> This was implemented in the operating system by the Waiting
> Conditions module and covered other conditions, like file
> not present, tape not present, pack not present, etc. and
> would allow the operator to continue the job when the waiting
> condition was resolved (it would continue automatically if
> the condition corrected itself, like a tape drive coming
> on-line and the label matching that requested by the program,
> or another job leaving the mix and relinquishing its memory).
>
> The operator could, in the case of non-existent file, redirect
> the program to a different file, if required.
>
> This was easier to do in the mainframe because the 'command interpreter',
> such as it was, was implemented in the kernel and thus was not itself
> subject to the waiting conditions, but this could be done with linux
> someday (albeit implemented a bit differently).
This means resources allocated for this 'command interpreter'.
I'd prefer having a fraction of swap space reserved for emergency.
When free swap is < 5MB (say), the system may go in emergency mode: all
processes stopped, last 5MB of swap enabled, /bin/sh launched on console:
it gets up to 5MB of RAM by paging out random pages (no fair eviction
algorithm need on emergency), onto the 5MB swap area.
The operator may inspect, kill or add tmp swap space, then exit the shell.
When the shell exits, the system continues as before. At this point,
more swap space is available.
Clearly not a viable solution for everyone. You may choose to run a non
interactive program which tries its best, when the operator is absent.
Maybe it's just Rik's killer. Kernel data needed to take the "best" guess
may be made accessible to the process. (User or kernel land is not
important. The process runs riks_killer(). It may be a userland function
or a system call - what comes first)
The price for this is 5MB of swap, and kernel support for
"OOM-Emergency-Mode". A scheduler issue, i guess. All processes, but
the emergency shell, should be flagged as 'EMERGENCY-STOPPED'.
Anyway, it sounds to me quite an hack. Out of swap should be avoided, not
cured, on any production system.
>
> scott
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@ESI.it
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:33 EST