Richard Gooch <rgooch@ras.ucalgary.ca>:
> Linda Walsh writes:
> > Richard Gooch wrote:
> > > Because it's different (read harder)? I still haven't seen a
> > > description of how we handle stack exhaustion properly. All we can do
> > > there is kill the offending process.
> > >
> >
> > Naw....we have lots of options. The first and best 1) A gram
> > of prevention is worth a kilogram of cure. If the developer or user
> > knows that a given program uses alot of stack space, then an option
> > in 'ld' to specify size of stack to commit, or 2) User says "runprog
> > -stacksize=1M <programname>" or some such option -- and 1M of stack
> > space is committed/reserved before when loading the program. 3) We
> > use a signal -- I sorta like overuse of SIGSTKFLT, but there may be
> > reasons not to use it. If in default, program dies as from a SEGV,
> > and 4) if ignored, program is put to sleep waiting on free pages.
>
> Each of these options is flawed:
>
> 1&2) you have to do this for all processes
Not really - this comes under system tuning -
1) the minimum allocated (initial) swap should be large enough for all the
standard utilities. This is limited to around 8-16K. There are others that
need more (sort). The inital allocation size should be either a per-user
amount, or a system global (or both).
2) This gives the user the option to request a larger initial stack for
unusual processes (say GIMP).
> 3) you can't handle a signal caused by stack exhaustion
True, unless you use a soft limit vs hard limit. The softlimit signal occurs
when the last allocated page of stack is used. This gives the time (and stack)
space to catch the signal and potentially allocate more.
> 4) deadlock.
That depends on the level of deadlock - If only user processes deadlock then
the kernel can still report the deadlock (and request an expansion of swap...)
This soft deadlock usually clears itself after several minutes (not always).
If it is a hard deadlock (no possibility of extraction, we assume a hard
deadlock 5-10 minutes after we see a soft deadlock message), the kernel can
still report it, and then use something like the OOM killer.
In both cases, the system has been operated in an overcommited mode.
>
> > Ok, maybe that wasn't lots, but it was at least 4! :-)
>
> That was 4 null options. I'd settle for one that could be shown to
> work, or at least reasonably expected to.
>
> > Not to sound repetitious, but why is lack of memory (a resource as
> > David puts it) so different from #processes, #open files/system /process,
> > out of diskspace on a write call, unable to acquire a 'lock' resource...
> >
> > Those just return error's or 'sleep'. Why should we come up with
> > a new paradigm for memory?
>
> Because there isn't always syscall interface for getting memory.
You don't really need one. The only non-syscall interface is stack allocation.
Three approaches have been outlined, and both are viable, even if #2 requires
some action on the part of the user.
> Look, I think it would be nice you you could provably ensure that
> processes can be made safe from OOM. Some people will like that. But
> until a lightweight, effective scheme is proposed that can support it,
> I think we should steer clear of ad-hoc solutions that only give half
> guarantees. It's better not to claim something at all than claim it
> and people find out later it's not true.
It isn't really all that ad-hock. This has been done in other UNIX versions
and has worked.
One way to get option #3 implemented for all processes is to embed it in
the process initialzation phase (before main() is called). This is the way
it's done in UNICOS.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
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 : Fri Mar 31 2000 - 21:00:19 EST