Short version:
Under very heavy thrashing (about four hours) the system either lockups
or OOM handler kills a task even when there is swap space left.
Long version:
My system is a dual 2x200MMX in a Gigabyte 586DX with 96Mb and 226Mb of
swap this way:
[root@quartz ~]# swapon -s
Filename Type Size Used Priority
/dev/hda7 partition 96348 6456 1
/dev/hdc6 partition 130276 6460 1
Well, I have tried to compile Mozilla 0.8.1 since the day it came out,
but I always lockup in the same place, wich it's begining to be a bit
frustrating ;-)
The problem is that compiling the file
content/base/src/nsStyleContext.o makes cc1plus grow up to a size of
141M, at this point the system is in heavy thrashing, kswapd is using
about 7-12% of CPU time and cc1plus is using 8-14%.
If I use a SMP kernel the system always ends up frozen, some times after
about almost one day of uptime and compiling since booting, and another
times it gets frozen in much less time, three or four hours.
If I use a non SMP kernel the system doesn't lokup but after some hours,
it varies between 6-8h, the cc1plus procces get a kill signal by OOM
killer, althought there is plenty of swap space left ((96Mb RAM + 226Mb
swap) - (140Mb - tiny amount used by the system) = plenty ;-).
For this tries I have left the system in single user, so no cron jobs,
no network trafic, no etc...
I suspect there is a race in the swap handling in SMP, and that the OOM
doesn't take into account the swap space left sometimes.
I don't know what to try next, suggestions?
--
Jorge Nerin
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
