On Wed, 30 Mar 2005 19:01:17 -0500
Mike Edwards <[EMAIL PROTECTED]> wrote:
> The reason I asked was because the IBM article I linked to earlier
> seemed to indicate the problem cropped up on 64 bit systems.
That problem in that article is S390 platform specific. They
use these higher-order allocations for the S390 page tables.
Sparc64 only uses up to order 1 allocations for it's page tables
so wouldn't trigger the bug you saw.
> In any case, I can't recall coming across this issue before, and most
> of the systems I run have far less memory than this beast. :)
>
> Is there a way to fix this?
Try to find out what is asking for such a large allocation. You
can do that by applying a patch similar to this one so that the
debug message prints out more information:
===== mm/page_alloc.c 1.72 vs edited =====
--- 1.72/mm/page_alloc.c 2004-08-08 01:58:48 -07:00
+++ edited/mm/page_alloc.c 2005-03-30 16:21:23 -08:00
@@ -476,6 +476,8 @@
out:
printk(KERN_NOTICE "__alloc_pages: %u-order allocation failed
(gfp=0x%x/%i)\n",
order, gfp_mask, !!(current->flags & PF_MEMALLOC));
+ printk(KERN_NOTICE "__alloc_pages: task(%s) pid(%d) caller(%p)\n",
+ current->comm, current->pid, __builtin_return_address(0));
if (unlikely(vm_gfp_debug))
dump_stack();
return NULL;
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
