Thread (3 messages) 3 messages, 2 authors, 2007-08-09

Re: [PATCH 00/23] per device dirty throttling -v8

From: <hidden>
Date: 2007-08-09 05:15:46
Also in: linux-mm, lkml

On Sat, 4 Aug 2007, Ray Lee wrote:
On 8/4/07, david@lang.hm [off-list ref] wrote:
quoted
On Sat, 4 Aug 2007, Ingo Molnar wrote:
At least on a surface level, your report has some similarities to
http://lkml.org/lkml/2007/5/21/84 . In that message, John Miller
mentions several things he tried without effect:

< - I increased the max allowed receive buffer through
< proc/sys/net/core/rmem_max and the application calls the right
< syscall. "netstat -su" does not show any "packet receive errors".
mercury1:/proc/sys/net/core# cat rmem_*
124928
131071
mercury1:/proc/sys/net/core# netstat -su
Udp:
     697853177 packets received
     10025642 packets to unknown port received.
     191726680 packet receive errors
     63194 packets sent
     RcvbufErrors: 191726680
UdpLite:
mercury1:/proc/sys/net/core# echo "512000" >rmem_max
< - After getting "kernel: swapper: page allocation failure.
< order:0, mode:0x20", I increased /proc/sys/vm/min_free_kbytes
I have not seen any similar errors
< - ixgb.txt in kernel network documentation suggests to increase
< net.core.netdev_max_backlog to 300000. This did not help.
mercury1:/proc/sys/net/core# cat netdev_*
300
1000
mercury1:/proc/sys/net/core# echo "300000" >netdev_max_backlog
< - I also had to increase net.core.optmem_max, because the default
< value was too small for 700 multicast groups.
I'm not running multicast.
As they're all pretty simple to test, it may be worthwhile to give
them a shot just to rule things out.
unfortunantly the load is not high enough right now to see a real 
difference (it's only doing ~1400 logs/sec) I'll catch it at a higher load 
point to see if these make any difference.

David Lang
Ray
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help