Re: why swap at all?

From: Tim Connors
Date: Mon Jun 07 2004 - 20:23:12 EST


John Bradford <john@xxxxxxxxxxxx> said on Tue, 1 Jun 2004 10:10:32 +0100:
> Quote from William Lee Irwin III <wli@xxxxxxxxxxxxxx>:
> > Quote from William Lee Irwin III <wli@xxxxxxxxxxxxxx>:
> > > to reproduce these 'swap increases performance even with untouched RAM'
> > > claims.
> >
> > Because ZONE_DMA, the lower 16MB is not all of RAM.
>
> Ah, OK, this isn't really my area of expertise so maybe this is a stupid, (for
> LKML), question, but can we only migrate data from low RAM via swap!?
>
> Also, surely this is only relevant to X86 architectures?


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:

Jun 8 07:55:24 scuzzie kernel: VM: killing process xemacs
Jun 8 07:56:17 scuzzie kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Jun 8 07:56:17 scuzzie kernel: VM: killing process mailoops
Jun 8 07:57:30 scuzzie kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d0/0)
Jun 8 07:57:34 scuzzie kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Jun 8 07:57:35 scuzzie kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Jun 8 07:57:35 scuzzie kernel: VM: killing process sh
Jun 8 07:57:35 scuzzie kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Jun 8 07:57:35 scuzzie kernel: VM: killing process sh
Jun 8 07:57:38 scuzzie kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Jun 8 07:57:38 scuzzie kernel: VM: killing process ssh-agent
Jun 8 07:57:38 scuzzie kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Jun 8 07:57:38 scuzzie kernel: VM: killing process gunzip
Jun 8 07:57:40 scuzzie kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Jun 8 07:57:40 scuzzie kernel: VM: killing process gunzip
Jun 8 07:57:40 scuzzie kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Jun 8 07:57:40 scuzzie kernel: VM: killing process gunzip
Jun 8 07:57:41 scuzzie kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d0/0)
Jun 8 07:57:41 scuzzie kernel: ERROR: (device ide0(3,5)): txAbortCommit
Jun 8 07:57:41 scuzzie kernel: BUG at jfs_txnmgr.c:509 assert(tblk->next == 0)
Jun 8 07:57:41 scuzzie kernel: kernel BUG at jfs_txnmgr.c:509!
Jun 8 07:57:41 scuzzie kernel: invalid operand: 0000
Jun 8 07:57:41 scuzzie kernel: CPU: 0
Jun 8 07:57:41 scuzzie kernel: EIP: 0010:[txEnd+235/256] Not tainted
Jun 8 07:57:41 scuzzie kernel: EFLAGS: 00010282
Jun 8 07:57:41 scuzzie kernel: eax: 00000033 ebx: d0811c98 ecx: c12dc000 edx: cd9f5f7c
Jun 8 07:57:41 scuzzie kernel: esi: 00000102 edi: cfec1d60 ebp: cf4eb000 esp: c12ddf18
Jun 8 07:57:41 scuzzie kernel: ds: 0018 es: 0018 ss: 0018
Jun 8 07:57:41 scuzzie kernel: Process keventd (pid: 2, stackpage=c12dd000)
Jun 8 07:57:41 scuzzie kernel: Stack: c028ed43 c028f190 000001fd c028f180 fffffffb 00000102 cf4eb05c c017db9e
Jun 8 07:57:41 scuzzie kernel: 00000102 00000001 c12ddf54 00000000 00000000 c35c5220 c017dc0e c35c5220
Jun 8 07:57:41 scuzzie kernel: 00000000 00000001 c014d3f2 c35c5220 00000000 00000003 c12ddf88 c12ddf88
Jun 8 07:57:41 scuzzie kernel: Call Trace: [jfs_commit_inode+222/256] [jfs_write_inode+78/96] [try_to_sync_unused_inodes+466/480] [__run_task_queue+90/112] [cont
ext_thread+442/448]
Jun 8 07:57:41 scuzzie kernel: [context_thread+0/448] [rest_init+0/64] [arch_kernel_thread+46/64] [context_thread+0/448]
Jun 8 07:57:41 scuzzie kernel:
Jun 8 07:57:41 scuzzie kernel: Code: 0f 0b fd 01 90 f1 28 c0 e9 71 ff ff ff 90 8d b4 26 00 00 00
Jun 8 07:57:41 scuzzie kernel: <5>__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Jun 8 07:57:41 scuzzie kernel: VM: killing process gunzip
Jun 8 07:57:49 scuzzie kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Jun 8 07:57:49 scuzzie kernel: VM: killing process mozilla-bin
Jun 8 07:57:49 scuzzie kernel: __alloc_pages: 0-order allocation failed (gfp=0x1f0/0)
Jun 8 07:58:09 scuzzie wwwoffles[25878]: Cannot make a lock file for 'http/www.bom.gov.au/LkdPT+cpeS73Lf-picjpvUw' [Read-only file system].
Jun 8 07:58:58 scuzzie anacron[16529]: Job `cron.weekly' terminated (exit status: 1) (mailing output)
Jun 8 07:58:59 scuzzie modprobe: modprobe: cannot create /var/log/ksymoops/20040608.log Read-only file system
Jun 8 07:58:59 scuzzie modprobe: modprobe: cannot create /var/log/ksymoops/20040608.log Read-only file system
Jun 8 07:58:59 scuzzie anacron[16529]: Tried to mail output of job `cron.weekly', but mailer process (/usr/sbin/sendmail) exited with ststus 1
Jun 8 07:58:59 scuzzie anacron[16529]: Normal exit (2 jobs run)



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

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.

--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
Anyone seeking the "Relativistic Quantum Mechanics" soft option
course, may wish to leave now. -- Intro lecture to RQM
-
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/