Re: why swap at all?

[Denis Vlasenko]

On Tuesday 08 June 2004 04:18, Tim Connors wrote:
> I just got an interesting problem - possibly (or not?) related to
> this:
>
> I have my laptop with 256MB of RAM, running 2.4.25-pre7, uptime 48
> days. Every morning, I come in and have to wait 2 minutes while
> everything comes back into RAM, after the daily slocate. So I did a
> swapoff -a, and it failed despite all the applications and cache and
> tmpfs adding up to far less than 256MB (more like 128).
>
> I closed mozilla, which let me do a swapoff -a.
>
> All was well for a few days, but then thismorning, my partitions were
> mounted ro, and an oops was in syslog at the same time as all the
> slocate work:
[alloc failures + oops snipped]

prolonged oom condition triggers lots of rarely user error paths
in kernel (and applications). Most probably slocate hit one of bugs
still living in one of them.

> So OOM - but why? The cache was registering 65MB used.
> 24353,23> cat /proc/meminfo
>         total:    used:    free:  shared: buffers:  cached:
> Mem:  262647808 256618496  6029312        0  4820992 67239936
> Swap:        0        0        0
> MemTotal:       256492 kB
> MemFree:          5888 kB
> MemShared:           0 kB
> Buffers:          4708 kB
> Cached:          65664 kB
> SwapCached:          0 kB
> Active:          77944 kB
> Inactive:       142308 kB
> HighTotal:           0 kB
> HighFree:            0 kB
> LowTotal:       256492 kB
> LowFree:          5888 kB
> SwapTotal:           0 kB
> SwapFree:            0 kB

Maybe this is not the state of the meminfo at the time of oom
condition. oops killed the task and had freed its memory,
which is now used by cache.

> Why was it so eager to kill applications, and not reclaim some of that
> swap space? Is this a problem that is known on 2.4, and can't be fixed
> (I can't use 2.6 on my laptop yet, far too many problems to even
> start - eg the suspend to ram on APM thread).
>
> Is there another output of a /proc file you want? I'll try not to get
> the urge to use/reboot the box in the meantime.

vmstat log of this event may be useful.
-- 
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/