LKML: http://lkml.org/lkml/2012/10/24/27
Reported-by: Masaki Kimura <masaki.kimura.kz@hitachi.com>
+Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
--- /dev/null
+From aee77e4accbeb2c86b1d294cd84fec4a12dde3bd Mon Sep 17 00:00:00 2001
+From: Michal Schmidt <mschmidt@redhat.com>
+Date: Sun, 9 Sep 2012 13:55:26 +0000
+Subject: r8169: use unlimited DMA burst for TX
+
+From: Michal Schmidt <mschmidt@redhat.com>
+
+commit aee77e4accbeb2c86b1d294cd84fec4a12dde3bd upstream.
+
+The r8169 driver currently limits the DMA burst for TX to 1024 bytes. I have
+a box where this prevents the interface from using the gigabit line to its full
+potential. This patch solves the problem by setting TX_DMA_BURST to unlimited.
+
+The box has an ASRock B75M motherboard with on-board RTL8168evl/8111evl
+(XID 0c900880). TSO is enabled.
+
+I used netperf (TCP_STREAM test) to measure the dependency of TX throughput
+on MTU. I did it for three different values of TX_DMA_BURST ('5'=512, '6'=1024,
+'7'=unlimited). This chart shows the results:
+http://michich.fedorapeople.org/r8169/r8169-effects-of-TX_DMA_BURST.png
+
+Interesting points:
+ - With the current DMA burst limit (1024):
+ - at the default MTU=1500 I get only 842 Mbit/s.
+ - when going from small MTU, the performance rises monotonically with
+ increasing MTU only up to a peak at MTU=1076 (908 MBit/s). Then there's
+ a sudden drop to 762 MBit/s from which the throughput rises monotonically
+ again with further MTU increases.
+ - With a smaller DMA burst limit (512):
+ - there's a similar peak at MTU=1076 and another one at MTU=564.
+ - With unlimited DMA burst:
+ - at the default MTU=1500 I get nice 940 Mbit/s.
+ - the throughput rises monotonically with increasing MTU with no strange
+ peaks.
+
+Notice that the peaks occur at MTU sizes that are multiples of the DMA burst
+limit plus 52. Why 52? Because:
+ 20 (IP header) + 20 (TCP header) + 12 (TCP options) = 52
+
+The Realtek-provided r8168 driver (v8.032.00) uses unlimited TX DMA burst too,
+except for CFG_METHOD_1 where the TX DMA burst is set to 512 bytes.
+CFG_METHOD_1 appears to be the oldest MAC version of "RTL8168B/8111B",
+i.e. RTL_GIGA_MAC_VER_11 in r8169. Not sure if this MAC version really needs
+the smaller burst limit, or if any other versions have similar requirements.
+
+Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
+Acked-by: Francois Romieu <romieu@fr.zoreil.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/ethernet/realtek/r8169.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/realtek/r8169.c
++++ b/drivers/net/ethernet/realtek/r8169.c
+@@ -73,7 +73,7 @@
+ static const int multicast_filter_limit = 32;
+
+ #define MAX_READ_REQUEST_SHIFT 12
+-#define TX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */
++#define TX_DMA_BURST 7 /* Maximum PCI burst, '7' is unlimited */
+ #define SafeMtu 0x1c20 /* ... actually life sucks beyond ~7k */
+ #define InterFrameGap 0x03 /* 3 means InterFrameGap = the shortest one */
+
ipv6-setsockopt-ipipproto_ipv6-ipv6_minhopcount-forgot-to-set-return-value.patch
net-correct-check-in-dev_addr_del.patch
net-rps-fix-brokeness-causing-ooo-packets.patch
+tmpfs-change-final-i_blocks-bug-to-warning.patch
+r8169-use-unlimited-dma-burst-for-tx.patch
+xen-events-fix-rcu-warning-or-call-idle-notifier-after-irq_enter.patch
--- /dev/null
+From 0f3c42f522dc1ad7e27affc0a4aa8c790bce0a66 Mon Sep 17 00:00:00 2001
+From: Hugh Dickins <hughd@google.com>
+Date: Fri, 16 Nov 2012 14:15:04 -0800
+Subject: tmpfs: change final i_blocks BUG to WARNING
+
+From: Hugh Dickins <hughd@google.com>
+
+commit 0f3c42f522dc1ad7e27affc0a4aa8c790bce0a66 upstream.
+
+Under a particular load on one machine, I have hit shmem_evict_inode()'s
+BUG_ON(inode->i_blocks), enough times to narrow it down to a particular
+race between swapout and eviction.
+
+It comes from the "if (freed > 0)" asymmetry in shmem_recalc_inode(),
+and the lack of coherent locking between mapping's nrpages and shmem's
+swapped count. There's a window in shmem_writepage(), between lowering
+nrpages in shmem_delete_from_page_cache() and then raising swapped
+count, when the freed count appears to be +1 when it should be 0, and
+then the asymmetry stops it from being corrected with -1 before hitting
+the BUG.
+
+One answer is coherent locking: using tree_lock throughout, without
+info->lock; reasonable, but the raw_spin_lock in percpu_counter_add() on
+used_blocks makes that messier than expected. Another answer may be a
+further effort to eliminate the weird shmem_recalc_inode() altogether,
+but previous attempts at that failed.
+
+So far undecided, but for now change the BUG_ON to WARN_ON: in usual
+circumstances it remains a useful consistency check.
+
+Signed-off-by: Hugh Dickins <hughd@google.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+
+---
+ mm/shmem.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/mm/shmem.c
++++ b/mm/shmem.c
+@@ -595,7 +595,7 @@ static void shmem_evict_inode(struct ino
+ kfree(xattr->name);
+ kfree(xattr);
+ }
+- BUG_ON(inode->i_blocks);
++ WARN_ON(inode->i_blocks);
+ shmem_free_inode(inode->i_sb);
+ end_writeback(inode);
+ }
--- /dev/null
+From 772aebcefeff310f80e32b874988af0076cb799d Mon Sep 17 00:00:00 2001
+From: Mojiong Qiu <qiumojiong@gmail.com>
+Date: Tue, 6 Nov 2012 16:08:15 +0800
+Subject: xen/events: fix RCU warning, or Call idle notifier after irq_enter()
+
+From: Mojiong Qiu <qiumojiong@gmail.com>
+
+commit 772aebcefeff310f80e32b874988af0076cb799d upstream.
+
+exit_idle() should be called after irq_enter(), otherwise it throws:
+
+[ INFO: suspicious RCU usage. ]
+3.6.5 #1 Not tainted
+-------------------------------
+include/linux/rcupdate.h:725 rcu_read_lock() used illegally while idle!
+
+other info that might help us debug this:
+
+RCU used illegally from idle CPU!
+rcu_scheduler_active = 1, debug_locks = 1
+RCU used illegally from extended quiescent state!
+1 lock held by swapper/0/0:
+ #0: (rcu_read_lock){......}, at: [<ffffffff810e9fe0>] __atomic_notifier_call_chain+0x0/0x140
+
+stack backtrace:
+Pid: 0, comm: swapper/0 Not tainted 3.6.5 #1
+Call Trace:
+ <IRQ> [<ffffffff811259a2>] lockdep_rcu_suspicious+0xe2/0x130
+ [<ffffffff810ea10c>] __atomic_notifier_call_chain+0x12c/0x140
+ [<ffffffff810e9fe0>] ? atomic_notifier_chain_unregister+0x90/0x90
+ [<ffffffff811216cd>] ? trace_hardirqs_off+0xd/0x10
+ [<ffffffff810ea136>] atomic_notifier_call_chain+0x16/0x20
+ [<ffffffff810777c3>] exit_idle+0x43/0x50
+ [<ffffffff81568865>] xen_evtchn_do_upcall+0x25/0x50
+ [<ffffffff81aa690e>] xen_do_hypervisor_callback+0x1e/0x30
+ <EOI> [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
+ [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
+ [<ffffffff81061540>] ? xen_safe_halt+0x10/0x20
+ [<ffffffff81075cfa>] ? default_idle+0xba/0x570
+ [<ffffffff810778af>] ? cpu_idle+0xdf/0x140
+ [<ffffffff81a4d881>] ? rest_init+0x135/0x144
+ [<ffffffff81a4d74c>] ? csum_partial_copy_generic+0x16c/0x16c
+ [<ffffffff82520c45>] ? start_kernel+0x3db/0x3e8
+ [<ffffffff8252066a>] ? repair_env_string+0x5a/0x5a
+ [<ffffffff82520356>] ? x86_64_start_reservations+0x131/0x135
+ [<ffffffff82524aca>] ? xen_start_kernel+0x465/0x46
+
+Git commit 98ad1cc14a5c4fd658f9d72c6ba5c86dfd3ce0d5
+Author: Frederic Weisbecker <fweisbec@gmail.com>
+Date: Fri Oct 7 18:22:09 2011 +0200
+
+ x86: Call idle notifier after irq_enter()
+
+did this, but it missed the Xen code.
+
+Signed-off-by: Mojiong Qiu <mjqiu@tencent.com>
+Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/xen/events.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/xen/events.c
++++ b/drivers/xen/events.c
+@@ -1365,8 +1365,8 @@ void xen_evtchn_do_upcall(struct pt_regs
+ {
+ struct pt_regs *old_regs = set_irq_regs(regs);
+
+- exit_idle();
+ irq_enter();
++ exit_idle();
+
+ __xen_evtchn_do_upcall();
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
