Re: Kernel 2.6.9 Multiple Page Allocation Failures

From: Nick Piggin
Date: Fri Nov 12 2004 - 07:12:56 EST




Lukas Hejtmanek wrote:

On Wed, Nov 10, 2004 at 04:11:48PM -0200, Marcelo Tosatti wrote:

OK, do you have Nick watermark fixes in?

They increase the GFP_ATOMIC buffer (memory reserved for GFP_ATOMIC allocations)
significantly, which is exactly the case here.

Its in Andrew's -mm tree already (the last -mm-bk contains it).

Its attached just in case - hope it ends this story.


Well today it reported page allocation failure again. I remind that I have
increased socket buffers:
/sbin/sysctl -w net/core/rmem_max=8388608
/sbin/sysctl -w net/core/wmem_max=8388608
/sbin/sysctl -w net/core/rmem_default=1048576
/sbin/sysctl -w net/core/wmem_default=1048576
/sbin/sysctl -w net/ipv4/tcp_window_scaling=1
/sbin/sysctl -w net/ipv4/tcp_rmem="4096 1048576 8388608"
/sbin/sysctl -w net/ipv4/tcp_wmem="4096 1048576 8388608"
/sbin/ifconfig eth0 txqueuelen 1000

I've tried to incdease min_free_kbytes to 10240 and it did not help :(



OK. Occasional page allocation failures are not a problem, although
if it is an order-0 allocation it may be an idea to increase
min_free_kbytes a bit more.

I think you said earlier that you had min_free_kbytes set to 8192?
Well after applying my patch, the memory watermarks get squashed
down, so you'd want to set it to at least 16384 afterward. Maybe
more.

That shouldn't cause it to actually keep more memory free than
2.6.8 did with an 8192 setting.


-
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/