In the nightly ltp run against the bk 2.5 tree last night I saw this
show up in the logs.
It happened on the 2-way PIII-550, 2gb physical ram, but not on the
smaller UP box I test on.
mtest01: page allocation failure. order:0, mode:0x50
mtest01: page allocation failure. order:0, mode:0x50
mtest01: page allocation failure. order:0, mode:0x50
klogd: page allocation failure. order:0, mode:0x50
klogd: page allocation failure. order:0, mode:0x50
mtest01: page allocation failure. order:0, mode:0x50
klogd: page allocation failure. order:0, mode:0x50
klogd: page allocation failure. order:0, mode:0x50
klogd: page allocation failure. order:0, mode:0x50
klogd: page allocation failure. order:0, mode:0x50
klogd: page allocation failure. order:0, mode:0x50
...
...
The past few nights it's been failing from compile errors such as the
vmlinux.lds.S error and such so I'm not for certain that this was caused
by something that got introduced yesterday. It should be from something
pretty recent though.
Thanks,
Paul Larson
Paul Larson wrote:
>
> In the nightly ltp run against the bk 2.5 tree last night I saw this
> show up in the logs.
>
> It happened on the 2-way PIII-550, 2gb physical ram, but not on the
> smaller UP box I test on.
>
> mtest01: page allocation failure. order:0, mode:0x50
scsi, I assume?
This will be failed bounce buffer allocation attempts.
That's fine, normal. block will fall back to the mempool
and will wait.
Of course, your shouldn't be bounce buffering at all. This
is happening because of the block-highmem problem. There's
a workaround at
http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.33/2.5.33-mm4/broken-out/scsi_hack.patch
But please bear in mind, this "page allocation failure" message
is purely a developer diagnostic thing. The reason it is there
is so that if some random toaster driver oopses over a failure
to handle an allocation failure, the person who reports the bug
can say "I saw an allocation failure and then your driver crashed".
Which tells the driver developer where to look.
Under heavy load, page allocation attempts _will_ fail, and
that's OK. The mempool-backed memory will become available.
It's a bit CPU-inefficient, and I have code under test which
changes GFP_NOFS mempool allocators to not even bother trying
to enter page reclaim if the nonblocking allocation attempt
failed.