lkml.org 
[lkml]   [2001]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH][RFC] simpler __alloc_pages{_limit}
On Sat, 25 Aug 2001 21:24:40 +0200
Roger Larsson <roger.larsson@skelleftea.mail.telia.com> wrote:

> I would like to see from were these higher order allocs comes from.
> Please insert something like this:
>
> printk("pid=%d; __alloc_pages(gfp=0x%x, order=%ld, ...)\n",
> current->pid, gfp_mask, order);
> show_trace(NULL);

Ok, Roger (and all the others involved).
I am back with new tests for memory problems.
Current test setup is:

software: 2.4.10-pre1 with Marco Tosatti's latest mem patch.
hardware: P3 1GHz 1 GB RAM, Adaptec SCSI, IBM 36GB HD 100MBit Tulip (roughly :-)

I copy files from via NFS to the machine on a reiserfs partition and read a CD (with xcdroast) to the same partition (reading an image). A note on that: NFS is exported with option no_subtree_check, because otherwise it fails on low mem condition and truncates files. This effect _only_ shows when exporting a reiserfs filesystem, on ext2 works well. Thanks to Neil Brown for helping me find this out.

meminfo before test:

total: used: free: shared: buffers: cached:
Mem: 921726976 92602368 829124608 0 6684672 37040128
Swap: 271392768 0 271392768
MemTotal: 900124 kB
MemFree: 809692 kB
MemShared: 0 kB
Buffers: 6528 kB
Cached: 36172 kB
SwapCached: 0 kB
Active: 3672 kB
Inact_dirty: 39028 kB
Inact_clean: 0 kB
Inact_target: 704 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 900124 kB
LowFree: 809692 kB
SwapTotal: 265032 kB
SwapFree: 265032 kB

First experience during test: CPU load is pretty high (varying around 6 - 8), sometimes results from "cat /proc/meminfo" take half a minute to show up.
Anyway, everything runs ok (besides the fact that it looks slow) until reading the CD is done. Then this shows up:

Aug 28 13:08:20 admin kernel: __alloc_pages: 3-order allocation failed.
Aug 28 13:08:20 admin kernel: pid=1139; __alloc_pages(gfp=0x20, order=3, ...)
Aug 28 13:08:20 admin kernel: Call Trace: [_alloc_pages+22/24] [__get_free_pages+10/24] [<fdcec826>] [<fdcec8f5>] [<fdceb7d7>]
Aug 28 13:08:20 admin kernel: [<fdcec0f5>] [<fdcea589>] [_alloc_pages+22/24] [__get_free_pages+10/24] [<fdcec826>] [<fdcec8f5>]
Aug 28 13:08:20 admin kernel: [<fdceb6bd>] [filemap_nopage+171/1008] [do_no_page+90/244] [handle_mm_fault+97/192] [<fdce94aa>] [do_page_fault+0/1164]
Aug 28 13:08:20 admin kernel: [dentry_open+189/316] [filp_open+82/92] [do_fcntl+370/712] [sys_ioctl+443/532] [system_call+51/56]
Aug 28 13:08:20 admin kernel: __alloc_pages: 3-order allocation failed.
Aug 28 13:08:20 admin kernel: pid=1139; __alloc_pages(gfp=0x20, order=3, ...)
Aug 28 13:08:20 admin kernel: Call Trace: [_alloc_pages+22/24] [__get_free_pages+10/24] [<fdcec826>] [<fdcec8f5>] [<fdceb7d7>]
Aug 28 13:08:20 admin kernel: [<fdcec0f5>] [<fdcea589>] [_alloc_pages+22/24] [__get_free_pages+10/24] [<fdcec826>] [<fdcec8f5>]
Aug 28 13:08:20 admin kernel: [<fdceb6bd>] [filemap_nopage+171/1008] [do_no_page+90/244] [handle_mm_fault+97/192] [<fdce94aa>] [do_page_fault+0/1164]
Aug 28 13:08:20 admin kernel: [dentry_open+189/316] [filp_open+82/92] [do_fcntl+370/712] [sys_ioctl+443/532] [system_call+51/56]
Aug 28 13:08:20 admin kernel: __alloc_pages: 3-order allocation failed.
Aug 28 13:08:20 admin kernel: pid=1139; __alloc_pages(gfp=0x20, order=3, ...)
Aug 28 13:08:20 admin kernel: Call Trace: [_alloc_pages+22/24] [__get_free_pages+10/24] [<fdcec826>] [<fdcec8f5>] [<fdceb7d7>]
Aug 28 13:08:20 admin kernel: [<fdcec0f5>] [<fdcea589>] [_alloc_pages+22/24] [__get_free_pages+10/24] [<fdcec826>] [<fdcec8f5>]
Aug 28 13:08:20 admin kernel: [<fdceb6bd>] [filemap_nopage+171/1008] [do_no_page+90/244] [handle_mm_fault+97/192] [<fdce94aa>] [do_page_fault+0/1164]
Aug 28 13:08:20 admin kernel: [dentry_open+189/316] [filp_open+82/92] [do_fcntl+370/712] [sys_ioctl+443/532] [system_call+51/56]
Aug 28 13:08:20 admin kernel: __alloc_pages: 3-order allocation failed.
Aug 28 13:08:20 admin kernel: pid=1139; __alloc_pages(gfp=0x20, order=3, ...)
Aug 28 13:08:20 admin kernel: Call Trace: [_alloc_pages+22/24] [__get_free_pages+10/24] [<fdcec826>] [<fdcec8f5>] [<fdceb7d7>]
Aug 28 13:08:20 admin kernel: [<fdcec0f5>] [<fdcea589>] [_alloc_pages+22/24] [__get_free_pages+10/24] [<fdcec826>] [<fdcec8f5>]
Aug 28 13:08:20 admin kernel: [<fdceb6bd>] [filemap_nopage+171/1008] [do_no_page+90/244] [handle_mm_fault+97/192] [<fdce94aa>] [do_page_fault+0/1164]
Aug 28 13:08:20 admin kernel: [dentry_open+189/316] [filp_open+82/92] [do_fcntl+370/712] [sys_ioctl+443/532] [system_call+51/56]
Aug 28 13:08:20 admin kernel: __alloc_pages: 3-order allocation failed.
Aug 28 13:08:20 admin kernel: pid=1139; __alloc_pages(gfp=0x20, order=3, ...)
Aug 28 13:08:20 admin kernel: Call Trace: [_alloc_pages+22/24] [__get_free_pages+10/24] [<fdcec826>] [<fdcec8f5>] [<fdceb7d7>]
Aug 28 13:08:20 admin kernel: [<fdcec0f5>] [<fdcea589>] [_alloc_pages+22/24] [__get_free_pages+10/24] [<fdcec826>] [<fdcec8f5>]
Aug 28 13:08:20 admin kernel: [<fdceb6bd>] [filemap_nopage+171/1008] [do_no_page+90/244] [handle_mm_fault+97/192] [<fdce94aa>] [do_page_fault+0/1164]
Aug 28 13:08:20 admin kernel: [dentry_open+189/316] [filp_open+82/92] [do_fcntl+370/712] [sys_ioctl+443/532] [system_call+51/56]

meminfo shows:

total: used: free: shared: buffers: cached:
Mem: 921726976 918597632 3129344 0 26300416 783720448
Swap: 271392768 0 271392768
MemTotal: 900124 kB
MemFree: 3056 kB
MemShared: 0 kB
Buffers: 25684 kB
Cached: 765352 kB
SwapCached: 0 kB
Active: 66372 kB
Inact_dirty: 723020 kB
Inact_clean: 1644 kB
Inact_target: 5708 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 900124 kB
LowFree: 3056 kB
SwapTotal: 265032 kB
SwapFree: 265032 kB

I was a bit surprised by the kernel errors. I just wanted to start the CD compare to image, but these problems showed up before that.

If I can do any additional debugging, tell me. There are some unresolved addresses above, maybe I made some mistake with System.map (name System.map-2.4.10-pre1 should be ok, isn't it?)

Regards,
Stephan

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

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