From: hurtta@cs.Helsinki.FI (Kari E. Hurtta) Subject: Re: Lock-ups, init/login Date: 11 Feb 1992 07:44:29 GMT
In article <1992Feb9.191222.17780@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) wrote:
> Ok, there has been some talk about lock-ups with linux: notably when
> doing big compiles (linking gnu-emacs etc) or when having several
> programs running under the VC's. The only solution has been to reboot
> with ctrl-alt-del, and this has mostly resulted in a more-or-less
> destroyed filesystem (the problem is compounded by the fact that these
> lock-ups happen just when you are running the most memory-intensive
> programs, which often write to the disk as well). Happily this doesn't
> happen very often (I haven't got many reports about this).
>
> As far as I've been able to find out, the problem isn't a filesystem
> problem (directly that is: the filesystem is just the first casualty
> after a reboot) - it seems to be directly linked with memory usage.
> When linux gets low in memory, it doesn't just give up and terminate the
> process: it tries to swap things out (even on a nonswapping system it
> can swap executable pages out - they can be demand-loaded back when
> necessary).
>
> This is mostly good: it allows programs to run to completion even after
> the memory really got totally used up, but it doesn't cope too well with
> programs that don't want "just a couple more pages", but a /lot/ of
> them: it might eventually give up with a "out of memory" error and
> terminate one of the processes, but it seems linux stubbornly tries to
> run some programs when it thinks it can juggle the pages, but in reality
> the program is just totally trashing between 2 or more pages (one single
> machine-insns can result in several page exceptions).
>
> Even update doesn't get the time to run, and the result is a machine
> that seems totally dead, and won't sync. Not good (understatement of
> the year). If somebody (who knows about swapping etc) has some
> constructive ideas of how to solve the problem, I'd be interested: right
> now I don't want to release 0.13 before this is solved. My current idea
> is to look at which pages have recently been swapped out, and if linux
> notices that one page gets swapped out/in all the time, it just kills
> the process. I'll get it solved: I just wanted to warn people that this
> problem does exist.
Perhaps is good idea put limit to mininum size of process' working set.
Two rules:
1) If (process' number of pages in working set) <=
(mininum size of process' working set)
then don't outpage process page ie. don't decrease process working set
size
2) if (total number of pageable _memory_ pages) -
(number of process) * (mininum size of process' working set)
< (mininum size of process' working set)
then fork will failed
Rule 2 should guaranteen that there isn't deadlock and
rule 1 should guaranteen that process newer trashing between
two or more pages.
I suggested that mininum size of process' working set is ten pages.
This should be sufficient.
- K E H "Just one idea"