[nSLUG] Help: CPAN session "killed", "0-order allocation failed"

Ian Campbell ian at slu.ms
Wed May 13 17:37:16 ADT 2009


On Wed, May 13, 2009 at 05:13:53PM -0300, Mike Spencer wrote:
> 
> me> [cpan failed...]
> me> __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
> 
> Jason> Hmm, try adding some more swap space.
> 
> me> There's a 500M swap partition.  But what do you know?  There's no
> me> swap entry in /etc/fstab for swapon -a to see when it's run in
> me> rc.S.
> 
> So I added a line to /etc/fstab referencing /dev/hda1 as swap, ran
> swapon -a as root.  Then I tried the cpan command again.  This time,
> not only did cpan die, the shell, the instance of emacs in which the
> shell was running and X all died, leaving me at the command prompt in
> the console from which X had been started.  And dmesg reported:
> 
>     __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
>     VM: killing process xterm
> 
> Since the rule that stupidity is defined as "doing the same thing and
> expecting a different result" isn't true in the domain of heisenbugs,
> I did the same thing again.  Result was a successful fetch of the
> desired perl module, other required modules and graceful exit with no
> error messages.  Except in dmesg, where, once again, the message:
> 
>     __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
> 
> appeared.
> 
> Any thoughts?  Anybody?

I'm not sure it's really a heisenbug if you're repeating the same
action and getting the same response... in this case the symptoms are
different (different things being killed) but the cause is the same,
presumably they're trying to allocate memory and killed by the OOM
killer.

Only thoughts are what he already suggested. First, check to make sure
the swap is actually mounted (swapon -s) ... if that still doesn't
help, consider adding more as a test (you can use a regular swapfile,
don't need to partition or anything silly of course), since some
compiles can be... memory intensive. I've had to do that on very low
memory machines to build GCC.

The other option I suppose is that the kernel is in a bad state. Can
always try a reboot ;)

> Ian> [/usr/bin/]Top lies....
> 
> My mental image of RAM is essentially that of a C programmer (there's
> "heap" and you can have some when you ask) and CP/M Z80 assembler
> (single chunk of linearly addressed space, you can do anything you
> want as long as you don't scribble on the BDOS/BIOS.)  I don't
> understand "slab" cache.  If the system has allocated a slab but the
> slab is empty/unused, does it still show up in /usr/bin/top or
> /bin/free as "used"?  Or does a slab only get created by a non-kernel
> program?  Guess I have to do some reading.

Slabs are allocated by the kernel to hold the cache/buffers (and misc
other stuff, I think.) I don't know if they're ever allocated and then
not-used, I suspect not... but it's a moot point.

The memory is only 'used' if it's available. If an application
requests it the kernel will nuke that chunk of cache and give the
memory to the application... so while technically the memory is doing
something, it's still available to your application. top reports the
amount of memory in use including buffers/cache. Free does too, but it
also gives you the real number which is somewhat more useful.



More information about the nSLUG mailing list