lkml.org 
[lkml]   [1998]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux behaviour in low memory situations.
On Sun, Jul 19, 1998 at 08:30:56PM +0000, Linus Torvalds wrote:
> In article <19980719213937.08230@cerebro.laendle>,
> >All the newer kernels, though, just _stop_ (not even sysrq works) without an
> >oops, when there is no memory left (all 2.1.10x for example). Increasing
> >sys/vm/freepages does not help at all..
>
> Please tell me more about what you're doing.. I certainly see different

my machine is a 192MB dual-P-II. I either use no swap, or a dedictaed 64MB
swap partition. The behaviour in low-memory situations (this is, I really
stress the machine with some netscapesis (roughly) as
follows:

aprx.
kernel
version with swap no swap
2.1.9x swap heavy for a while, immediately kill a process
then just seems to stop
2.1.10x swap heavy for a while, just stop.
then just seems to stop

I can reproduce this exactly by simply recompiling a (very large) c++ file
(for which the compiler needs around 200MB VM).

with swap enabled, linux sometimes survives after really heavy swapping,
but not when I start netscape in parallel.

In the cases where swap is enabled, the computer does not seem to really
stop, it just pauses with disk activity for extended periods (minutes), and
I do never wait for longer than half an hour (this is the fsck vs. swap
tradeoff ;)

I got the idea of turning off swap when I found out that immediatelly
killing some process was more effective than swapping for ten minutes, then
stopping, then rebotting and fsck'ing.

Just for fun, I ran this test again from the console (without swap), and the
computer (almost) locked up, the console didn't react to pressing return,
but numlock worked. After pressing SysRq-S, I got:

SysRq: Emergency Sync

and the machine did NOT sync any drives and locked up hard (not even numlock
or SysRq-B worked).

Also, 2.1.109 (only) performance is very bad once memory has been used by
the buffer cache (I mean, free memory is around 9M), as if reclaiming
buffers took much time.

Also, a simple find /var/spool/news (on at least 2.1.108 & 109) gives me a
real 386 feeling. The window manager isn't able to redraw windows within a
second, the mouse cursor motion is very sluggish (the x server runs as a
realtime process), and this is on a _dual_ P-II system.

So, in general, 2.1.10x is very fast (compared to 2.0), when in good
condition, but as soon as memory gets even remotely tight (or I start find),
it gets almost unusable.

The 2.1.9x kernels were _much_ more usable for me.

-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@goof.com |e|
-=====/_/_//_/\_,_/ /_/\_\ --+
The choice of a GNU generation |
|

-
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.altern.org/andrebalsa/doc/lkml-faq.html

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.024 / U:0.836 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site