Re: commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 kills r8169 send performance
On Wed, 26 Sep 2007, Francois Romieu wrote: > Apply and try each patch of the attached tarball on top of 2.6.23-git > until the behavior changes (assuming it does). > > Patch #000n applies on top of patch #000(n - 1). I tested the series on top of -rc8 and 0005 did the trick. And if I use 0005 only, I can get 93MB/s send and 97MB/s receive, so there is a nice increase on send too since .22! iperf numbers (send/receive): revert.0001:[ 4] 0.0-10.1 sec234 MBytes194 Mbits/sec revert.0001:[ 5] 0.0-10.0 sec445 MBytes373 Mbits/sec revert.0002:[ 5] 0.0-10.0 sec325 MBytes272 Mbits/sec revert.0002:[ 4] 0.0-10.1 sec969 MBytes802 Mbits/sec revert.0003:[ 4] 0.0-10.1 sec328 MBytes272 Mbits/sec revert.0003:[ 5] 0.0-10.0 sec742 MBytes622 Mbits/sec revert.0004:[ 4] 0.0-10.2 sec329 MBytes271 Mbits/sec revert.0004:[ 5] 0.0-10.0 sec759 MBytes637 Mbits/sec revert.0005:[ 4] 0.0-10.1 sec829 MBytes691 Mbits/sec revert.0005:[ 5] 0.0-10.0 sec772 MBytes647 Mbits/sec revert.0005-only:[ 5] 0.0-10.0 sec933 MBytes780 Mbits/sec revert.0005-only:[ 4] 0.0-10.1 sec970 MBytes806 Mbits/sec //T > Good night. // / Timo Jantunen .. ZZZ (Used to represent :Kuunsäde 8 A 28: Email: [EMAIL PROTECTED] : the sound of a person snoring.) :FIN-02210 Espoo: http://iki.fi/jeti : Webster's Encyclopedic Unabridged :Finland: GSM+358-40-5763131 : Dictionary of the English Language :...::
Re: commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 kills r8169 send performance
On Wed, 26 Sep 2007, Francois Romieu wrote: Apply and try each patch of the attached tarball on top of 2.6.23-git until the behavior changes (assuming it does). Patch #000n applies on top of patch #000(n - 1). I tested the series on top of -rc8 and 0005 did the trick. And if I use 0005 only, I can get 93MB/s send and 97MB/s receive, so there is a nice increase on send too since .22! iperf numbers (send/receive): revert.0001:[ 4] 0.0-10.1 sec234 MBytes194 Mbits/sec revert.0001:[ 5] 0.0-10.0 sec445 MBytes373 Mbits/sec revert.0002:[ 5] 0.0-10.0 sec325 MBytes272 Mbits/sec revert.0002:[ 4] 0.0-10.1 sec969 MBytes802 Mbits/sec revert.0003:[ 4] 0.0-10.1 sec328 MBytes272 Mbits/sec revert.0003:[ 5] 0.0-10.0 sec742 MBytes622 Mbits/sec revert.0004:[ 4] 0.0-10.2 sec329 MBytes271 Mbits/sec revert.0004:[ 5] 0.0-10.0 sec759 MBytes637 Mbits/sec revert.0005:[ 4] 0.0-10.1 sec829 MBytes691 Mbits/sec revert.0005:[ 5] 0.0-10.0 sec772 MBytes647 Mbits/sec revert.0005-only:[ 5] 0.0-10.0 sec933 MBytes780 Mbits/sec revert.0005-only:[ 4] 0.0-10.1 sec970 MBytes806 Mbits/sec //T Good night. // / Timo Jantunen .. ZZZ (Used to represent :Kuunsäde 8 A 28: Email: [EMAIL PROTECTED] : the sound of a person snoring.) :FIN-02210 Espoo: http://iki.fi/jeti : Webster's Encyclopedic Unabridged :Finland: GSM+358-40-5763131 : Dictionary of the English Language :...::
Re: commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 kills r8169 send performance
Timo Jantunen <[EMAIL PROTECTED]> : [...] > Thanks for the quick reply and fix. Unfortunately the fix didn't help in my > case. Apply and try each patch of the attached tarball on top of 2.6.23-git until the behavior changes (assuming it does). Patch #000n applies on top of patch #000(n - 1). Good night. -- Ueimor r8169-timo-20070926.tgz Description: GNU Zip compressed data
Re: commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 kills r8169 send performance
On Wed, 26 Sep 2007, Willy Tarreau wrote: > On Wed, Sep 26, 2007 at 09:52:02PM +0300, Timo Jantunen wrote: > > On Wed, 26 Sep 2007, Francois Romieu wrote: > > > The patch below is scheduled for inclusion before 2.6.23. Please try it > > > and > > > see if it makes a difference on top of 2.6.23-rc8 (full dmesg will be > > > welcome > > > too). > > Thanks for the quick reply and fix. Unfortunately the fix didn't help in my > > case. > > In another thread on LKML today, there has been some discussion about a > similar problem, which is caused by a locking bug in iperf which makes > it spin at 100% CPU. Ingo has posted a fix for this, please check the list. I noticed the problem originally with another program (playback of 720p video to remote X using mplayer). And in my case the CPU usage is 2-3% systime, <1% userspace so it doesn't seem to be anything to do with the scheduler (I did try that "echo 1 > /proc/sys/kernel/sched_compat_yield" workaround, too.) //T > Regards, > Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 kills r8169 send performance
On Wed, Sep 26, 2007 at 09:52:02PM +0300, Timo Jantunen wrote: > On Wed, 26 Sep 2007, Francois Romieu wrote: > > > The patch below is scheduled for inclusion before 2.6.23. Please try it and > > see if it makes a difference on top of 2.6.23-rc8 (full dmesg will be > > welcome > > too). > > Thanks for the quick reply and fix. Unfortunately the fix didn't help in my > case. In another thread on LKML today, there has been some discussion about a similar problem, which is caused by a locking bug in iperf which makes it spin at 100% CPU. Ingo has posted a fix for this, please check the list. Regards, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 kills r8169 send performance
On Wed, 26 Sep 2007, Francois Romieu wrote: > The patch below is scheduled for inclusion before 2.6.23. Please try it and > see if it makes a difference on top of 2.6.23-rc8 (full dmesg will be welcome > too). Thanks for the quick reply and fix. Unfortunately the fix didn't help in my case. Iperf readings (send+receive) from 2.6.23-git (just before 6dccd... commit) [ 5] 0.0-10.0 sec830 MBytes694 Mbits/sec [ 4] 0.0-10.0 sec842 MBytes706 Mbits/sec 2.3.23-rc8 (clean) [ 4] 0.0-10.0 sec323 MBytes270 Mbits/sec [ 5] 0.0-10.0 sec961 MBytes802 Mbits/sec 2.3.23-rc8 and your patch [ 5] 0.0-10.1 sec326 MBytes270 Mbits/sec [ 4] 0.0-10.0 sec958 MBytes802 Mbits/sec 2.3.23-rc8 and 6dccd... reverted [ 5] 0.0-10.1 sec830 MBytes692 Mbits/sec [ 4] 0.0-10.0 sec803 MBytes673 Mbits/sec and full dmesg from 2.3.23-rc8+your patch below. Dmesg from other versions differed only by random noise caused by minor variations on bogomips scores, async initializations etc. I can send them to you too, if you think they are useful. ===cut Linux version 2.6.23-rc8-fix ([EMAIL PROTECTED]) (gcc version 4.2.0 (Gentoo 4.2.0 p1.4)) #2 SMP Wed Sep 26 21:24:43 EEST 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009e400 (usable) BIOS-e820: 0009e400 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 7fee (usable) BIOS-e820: 7fee - 7fee3000 (ACPI NVS) BIOS-e820: 7fee3000 - 7fef (ACPI data) BIOS-e820: 7fef - 7ff0 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - 0001 (reserved) 1150MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000f3640 NX (Execute Disable) protection: active Entering add_active_range(0, 0, 524000) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 229376 HighMem229376 -> 524000 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -> 524000 On node 0 totalpages: 524000 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 1760 pages used for memmap Normal zone: 223520 pages, LIFO batch:31 HighMem zone: 2301 pages used for memmap HighMem zone: 292323 pages, LIFO batch:31 Movable zone: 0 pages used for memmap DMI 2.5 present. ACPI: RSDP 000F77F0, 0014 (r0 IntelR) ACPI: RSDT 7FEE3000, 0034 (r1 IntelR AWRDACPI 42302E31 AWRD0) ACPI: FACP 7FEE3080, 0074 (r1 IntelR AWRDACPI 42302E31 AWRD0) ACPI: DSDT 7FEE3100, 4D1C (r1 INTELR AWRDACPI 1000 MSFT 300) ACPI: FACS 7FEE, 0040 ACPI: MCFG 7FEE7F00, 003C (r1 IntelR AWRDACPI 42302E31 AWRD0) ACPI: APIC 7FEE7E40, 0084 (r1 IntelR AWRDACPI 42302E31 AWRD0) ACPI: SSDT 7FEE8860, 0380 (r1 PmRefCpuPm 3000 INTL 20041203) ACPI: PM-Timer IO Port: 0x408 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 6:15 APIC version 20 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x03] enabled) Processor #3 6:15 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 6:15 APIC version 20 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) Processor #2 6:15 APIC version 20 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1]) ACPI: IOAPIC (id[0x04] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 4, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 8000 (gap: 7ff0:6010) Built 1 zonelists in Zone order. Total pages: 519907 Kernel command line: ro root=/dev/sdb2 [EMAIL PROTECTED]/eth0,[EMAIL PROTECTED]/ video=vesafb:ypan,mtrr:3 vga=0x0376 netconsole: local port 2001 netconsole: local IP 10.0.0.1 netconsole: interface eth0 netconsole: remote port 2001 netconsole: remote IP 10.0.0.254 netconsole: remote ethernet address ff:ff:ff:ff:ff:ff mapped APIC to b000 (fee0) mapped IOAPIC to a000 (fec0) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 4096 (order: 12, 16384 bytes) Detected 2403.193 MHz processor. Console: colour dummy device 80x25 console [tty0] enabled Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory:
Re: commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 kills r8169 send performance
Timo Jantunen <[EMAIL PROTECTED]> :
[...]
> Git bisect gave commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 as the
> culprit, and reverting it from the 2.6.23-rc8 increases send speed back to
> .22 level. (It didn't revert cleanly and the file needed some cleaning up
> by hand.)
You are welcome but you are late.
The patch below is scheduled for inclusion before 2.6.23. Please try it and
see if it makes a difference on top of 2.6.23-rc8 (full dmesg will be welcome
too).
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index b85ab4a..c921ec3 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1228,7 +1228,10 @@ static void rtl8169_hw_phy_config(struct net_device *dev)
return;
}
- /* phy config for RTL8169s mac_version C chip */
+ if ((tp->mac_version != RTL_GIGA_MAC_VER_02) &&
+ (tp->mac_version != RTL_GIGA_MAC_VER_03))
+ return;
+
mdio_write(ioaddr, 31, 0x0001); //w 31 2 0 1
mdio_write(ioaddr, 21, 0x1000); //w 21 15 0 1000
mdio_write(ioaddr, 24, 0x65c7); //w 24 15 0 65c7
@@ -2567,6 +2570,15 @@ static void rtl8169_tx_interrupt(struct net_device *dev,
(TX_BUFFS_AVAIL(tp) >= MAX_SKB_FRAGS)) {
netif_wake_queue(dev);
}
+ /*
+* 8168 hack: TxPoll requests are lost when the Tx packets are
+* too close. Let's kick an extra TxPoll request when a burst
+* of start_xmit activity is detected (if it is not detected,
+* it is slow enough). -- FR
+*/
+ smp_rmb();
+ if (tp->cur_tx != dirty_tx)
+ RTL_W8(TxPoll, NPQ);
}
}
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 kills r8169 send performance
Heip! (commit: "r8169: merge with version 6.001.00 of Realtek's r8169 driver") In current 2.6.23-rc8 snapshot r8169 send performance is bad, around 32MB/s. In 2.6.22 it was around 83MB/s. Interestingly, the receive performance has increased from around 85MB/s to 96MB/s at the same time! Git bisect gave commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 as the culprit, and reverting it from the 2.6.23-rc8 increases send speed back to .22 level. (It didn't revert cleanly and the file needed some cleaning up by hand.) Performance data: (The other end of iperf is machine with kernel 2.6.22.6 and nForce3 built-in nic.) 2.6.22 (and 2.6.23-rc8 with that change reverted) ===cut $ iperf -m -l32k -c gw -r Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) Client connecting to gw, TCP port 5001 TCP window size: 64.0 KByte (default) [ 5] local 10.0.0.1 port 36068 connected with 10.0.0.254 port 5001 [ 5] 0.0-10.0 sec832 MBytes696 Mbits/sec [ 5] MSS size 7148 bytes (MTU 7188 bytes, unknown interface) [ 4] local 10.0.0.1 port 5001 connected with 10.0.0.254 port 59713 [ 4] 0.0-10.2 sec825 MBytes678 Mbits/sec [ 4] MSS size 7148 bytes (MTU 7188 bytes, unknown interface) $ vmstat 2 procs ---memory-- ---swap-- -io -system-- cpu r b swpd free buff cache si sobibo in cs us sy id wa 0 0 0 1960780 2948 3294800 23611 48 327 2 3 86 9 0 0 0 1960660 2948 3297200 0 0 94 944 0 0 100 0 0 0 0 1960752 2952 329960014 0 90 233 0 0 100 0 0 0 0 1960776 2952 3299600 0 0 89 964 0 0 100 0 1 0 0 1959544 3044 3378800 42052 154 458 0 1 97 2 0 0 0 1940288 3080 3470400 43434 16075 2198 0 2 98 0 0 0 0 1940116 3080 3470400 0 0 16464 2835 0 1 99 0 0 0 0 1940020 3080 3470400 058 16590 2194 0 1 99 0 0 0 0 1940316 3080 3470400 0 0 16489 2887 0 1 99 0 0 0 0 1940268 3080 3470400 0 0 16505 2990 0 1 99 0 0 0 0 1957936 3080 3470400 0 4 23482 24903 0 2 98 0 0 0 0 1957720 3080 3470400 0 0 24270 29139 0 2 98 0 0 0 0 1957980 3080 3470400 0 4 22045 27621 0 2 98 0 1 0 0 1958004 3080 3470400 0 0 24383 30106 0 2 98 0 0 0 0 1957956 3080 3470400 0 0 21984 27709 0 2 98 0 0 0 0 1958112 3080 3470400 0 0 3083 5826 0 0 100 0 0 0 0 1958168 3080 3470400 0 0 83 2392 0 0 100 0 ===cut 2.6.23-rc8 without changes ===cut $ iperf -m -l32k -c gw -r Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) Client connecting to gw, TCP port 5001 TCP window size: 73.0 KByte (default) [ 5] local 10.0.0.1 port 55265 connected with 10.0.0.254 port 5001 [ 5] 0.0-10.1 sec328 MBytes272 Mbits/sec [ 5] MSS size 7148 bytes (MTU 7188 bytes, unknown interface) [ 4] local 10.0.0.1 port 5001 connected with 10.0.0.254 port 41340 [ 4] 0.0-10.0 sec964 MBytes805 Mbits/sec [ 4] MSS size 7148 bytes (MTU 7188 bytes, unknown interface) $ vmstat 2 procs ---memory-- ---swap-- -io -system-- cpu r b swpd free buff cache si sobibo in cs us sy id wa 0 0 0 1961244 3756 3158000 29213 52 331 2 4 84 10 0 0 0 1959916 3756 3236800 436 0 186 893 0 0 99 0 0 0 0 1944668 3756 3250400 0 0 7141 2223 0 2 98 0 0 0 0 1948260 3756 3250400 0 0 7012 2213 0 2 98 0 1 0 0 1946532 3756 3250400 0 0 7001 0 1 99 0 1 0 0 1942276 3756 3250400 0 0 6996 2168 0 2 98 0 1 0 0 1943336 3756 3250400 0 0 6946 2181 0 0 100 0 2 0 0 1959144 3848 3329600 42052 19020 24412 0 2 96 2 1 0 0 1959064 3884 3334400 082 21825 30835 0 3 97 0 0 0 0 1959152 3884 3334400 0 0 21816 32094 0 2 98 0 0 0 0 1959040 3884 3334400 0 6 21850 31934 0 3 96 0 2 0 0 1959072 3884 3334400 0 0 21812 32068 0 2 98 0 0 0 0 1959104 3884 3334400
commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 kills r8169 send performance
Heip! (commit: r8169: merge with version 6.001.00 of Realtek's r8169 driver) In current 2.6.23-rc8 snapshot r8169 send performance is bad, around 32MB/s. In 2.6.22 it was around 83MB/s. Interestingly, the receive performance has increased from around 85MB/s to 96MB/s at the same time! Git bisect gave commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 as the culprit, and reverting it from the 2.6.23-rc8 increases send speed back to .22 level. (It didn't revert cleanly and the file needed some cleaning up by hand.) Performance data: (The other end of iperf is machine with kernel 2.6.22.6 and nForce3 built-in nic.) 2.6.22 (and 2.6.23-rc8 with that change reverted) ===cut $ iperf -m -l32k -c gw -r Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) Client connecting to gw, TCP port 5001 TCP window size: 64.0 KByte (default) [ 5] local 10.0.0.1 port 36068 connected with 10.0.0.254 port 5001 [ 5] 0.0-10.0 sec832 MBytes696 Mbits/sec [ 5] MSS size 7148 bytes (MTU 7188 bytes, unknown interface) [ 4] local 10.0.0.1 port 5001 connected with 10.0.0.254 port 59713 [ 4] 0.0-10.2 sec825 MBytes678 Mbits/sec [ 4] MSS size 7148 bytes (MTU 7188 bytes, unknown interface) $ vmstat 2 procs ---memory-- ---swap-- -io -system-- cpu r b swpd free buff cache si sobibo in cs us sy id wa 0 0 0 1960780 2948 3294800 23611 48 327 2 3 86 9 0 0 0 1960660 2948 3297200 0 0 94 944 0 0 100 0 0 0 0 1960752 2952 329960014 0 90 233 0 0 100 0 0 0 0 1960776 2952 3299600 0 0 89 964 0 0 100 0 1 0 0 1959544 3044 3378800 42052 154 458 0 1 97 2 0 0 0 1940288 3080 3470400 43434 16075 2198 0 2 98 0 0 0 0 1940116 3080 3470400 0 0 16464 2835 0 1 99 0 0 0 0 1940020 3080 3470400 058 16590 2194 0 1 99 0 0 0 0 1940316 3080 3470400 0 0 16489 2887 0 1 99 0 0 0 0 1940268 3080 3470400 0 0 16505 2990 0 1 99 0 0 0 0 1957936 3080 3470400 0 4 23482 24903 0 2 98 0 0 0 0 1957720 3080 3470400 0 0 24270 29139 0 2 98 0 0 0 0 1957980 3080 3470400 0 4 22045 27621 0 2 98 0 1 0 0 1958004 3080 3470400 0 0 24383 30106 0 2 98 0 0 0 0 1957956 3080 3470400 0 0 21984 27709 0 2 98 0 0 0 0 1958112 3080 3470400 0 0 3083 5826 0 0 100 0 0 0 0 1958168 3080 3470400 0 0 83 2392 0 0 100 0 ===cut 2.6.23-rc8 without changes ===cut $ iperf -m -l32k -c gw -r Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) Client connecting to gw, TCP port 5001 TCP window size: 73.0 KByte (default) [ 5] local 10.0.0.1 port 55265 connected with 10.0.0.254 port 5001 [ 5] 0.0-10.1 sec328 MBytes272 Mbits/sec [ 5] MSS size 7148 bytes (MTU 7188 bytes, unknown interface) [ 4] local 10.0.0.1 port 5001 connected with 10.0.0.254 port 41340 [ 4] 0.0-10.0 sec964 MBytes805 Mbits/sec [ 4] MSS size 7148 bytes (MTU 7188 bytes, unknown interface) $ vmstat 2 procs ---memory-- ---swap-- -io -system-- cpu r b swpd free buff cache si sobibo in cs us sy id wa 0 0 0 1961244 3756 3158000 29213 52 331 2 4 84 10 0 0 0 1959916 3756 3236800 436 0 186 893 0 0 99 0 0 0 0 1944668 3756 3250400 0 0 7141 2223 0 2 98 0 0 0 0 1948260 3756 3250400 0 0 7012 2213 0 2 98 0 1 0 0 1946532 3756 3250400 0 0 7001 0 1 99 0 1 0 0 1942276 3756 3250400 0 0 6996 2168 0 2 98 0 1 0 0 1943336 3756 3250400 0 0 6946 2181 0 0 100 0 2 0 0 1959144 3848 3329600 42052 19020 24412 0 2 96 2 1 0 0 1959064 3884 3334400 082 21825 30835 0 3 97 0 0 0 0 1959152 3884 3334400 0 0 21816 32094 0 2 98 0 0 0 0 1959040 3884 3334400 0 6 21850 31934 0 3 96 0 2 0 0 1959072 3884 3334400 0 0 21812 32068 0 2 98 0 0 0 0 1959104 3884 3334400
Re: commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 kills r8169 send performance
Timo Jantunen [EMAIL PROTECTED] :
[...]
Git bisect gave commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 as the
culprit, and reverting it from the 2.6.23-rc8 increases send speed back to
.22 level. (It didn't revert cleanly and the file needed some cleaning up
by hand.)
You are welcome but you are late.
The patch below is scheduled for inclusion before 2.6.23. Please try it and
see if it makes a difference on top of 2.6.23-rc8 (full dmesg will be welcome
too).
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index b85ab4a..c921ec3 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1228,7 +1228,10 @@ static void rtl8169_hw_phy_config(struct net_device *dev)
return;
}
- /* phy config for RTL8169s mac_version C chip */
+ if ((tp-mac_version != RTL_GIGA_MAC_VER_02)
+ (tp-mac_version != RTL_GIGA_MAC_VER_03))
+ return;
+
mdio_write(ioaddr, 31, 0x0001); //w 31 2 0 1
mdio_write(ioaddr, 21, 0x1000); //w 21 15 0 1000
mdio_write(ioaddr, 24, 0x65c7); //w 24 15 0 65c7
@@ -2567,6 +2570,15 @@ static void rtl8169_tx_interrupt(struct net_device *dev,
(TX_BUFFS_AVAIL(tp) = MAX_SKB_FRAGS)) {
netif_wake_queue(dev);
}
+ /*
+* 8168 hack: TxPoll requests are lost when the Tx packets are
+* too close. Let's kick an extra TxPoll request when a burst
+* of start_xmit activity is detected (if it is not detected,
+* it is slow enough). -- FR
+*/
+ smp_rmb();
+ if (tp-cur_tx != dirty_tx)
+ RTL_W8(TxPoll, NPQ);
}
}
--
Ueimor
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 kills r8169 send performance
On Wed, 26 Sep 2007, Francois Romieu wrote: The patch below is scheduled for inclusion before 2.6.23. Please try it and see if it makes a difference on top of 2.6.23-rc8 (full dmesg will be welcome too). Thanks for the quick reply and fix. Unfortunately the fix didn't help in my case. Iperf readings (send+receive) from 2.6.23-git (just before 6dccd... commit) [ 5] 0.0-10.0 sec830 MBytes694 Mbits/sec [ 4] 0.0-10.0 sec842 MBytes706 Mbits/sec 2.3.23-rc8 (clean) [ 4] 0.0-10.0 sec323 MBytes270 Mbits/sec [ 5] 0.0-10.0 sec961 MBytes802 Mbits/sec 2.3.23-rc8 and your patch [ 5] 0.0-10.1 sec326 MBytes270 Mbits/sec [ 4] 0.0-10.0 sec958 MBytes802 Mbits/sec 2.3.23-rc8 and 6dccd... reverted [ 5] 0.0-10.1 sec830 MBytes692 Mbits/sec [ 4] 0.0-10.0 sec803 MBytes673 Mbits/sec and full dmesg from 2.3.23-rc8+your patch below. Dmesg from other versions differed only by random noise caused by minor variations on bogomips scores, async initializations etc. I can send them to you too, if you think they are useful. ===cut Linux version 2.6.23-rc8-fix ([EMAIL PROTECTED]) (gcc version 4.2.0 (Gentoo 4.2.0 p1.4)) #2 SMP Wed Sep 26 21:24:43 EEST 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009e400 (usable) BIOS-e820: 0009e400 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 7fee (usable) BIOS-e820: 7fee - 7fee3000 (ACPI NVS) BIOS-e820: 7fee3000 - 7fef (ACPI data) BIOS-e820: 7fef - 7ff0 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - 0001 (reserved) 1150MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000f3640 NX (Execute Disable) protection: active Entering add_active_range(0, 0, 524000) 0 entries of 256 used Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 229376 HighMem229376 - 524000 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 - 524000 On node 0 totalpages: 524000 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 1760 pages used for memmap Normal zone: 223520 pages, LIFO batch:31 HighMem zone: 2301 pages used for memmap HighMem zone: 292323 pages, LIFO batch:31 Movable zone: 0 pages used for memmap DMI 2.5 present. ACPI: RSDP 000F77F0, 0014 (r0 IntelR) ACPI: RSDT 7FEE3000, 0034 (r1 IntelR AWRDACPI 42302E31 AWRD0) ACPI: FACP 7FEE3080, 0074 (r1 IntelR AWRDACPI 42302E31 AWRD0) ACPI: DSDT 7FEE3100, 4D1C (r1 INTELR AWRDACPI 1000 MSFT 300) ACPI: FACS 7FEE, 0040 ACPI: MCFG 7FEE7F00, 003C (r1 IntelR AWRDACPI 42302E31 AWRD0) ACPI: APIC 7FEE7E40, 0084 (r1 IntelR AWRDACPI 42302E31 AWRD0) ACPI: SSDT 7FEE8860, 0380 (r1 PmRefCpuPm 3000 INTL 20041203) ACPI: PM-Timer IO Port: 0x408 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 6:15 APIC version 20 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x03] enabled) Processor #3 6:15 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 6:15 APIC version 20 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) Processor #2 6:15 APIC version 20 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1]) ACPI: IOAPIC (id[0x04] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 4, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 8000 (gap: 7ff0:6010) Built 1 zonelists in Zone order. Total pages: 519907 Kernel command line: ro root=/dev/sdb2 [EMAIL PROTECTED]/eth0,[EMAIL PROTECTED]/ video=vesafb:ypan,mtrr:3 vga=0x0376 netconsole: local port 2001 netconsole: local IP 10.0.0.1 netconsole: interface eth0 netconsole: remote port 2001 netconsole: remote IP 10.0.0.254 netconsole: remote ethernet address ff:ff:ff:ff:ff:ff mapped APIC to b000 (fee0) mapped IOAPIC to a000 (fec0) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 4096 (order: 12, 16384 bytes) Detected 2403.193 MHz processor. Console: colour dummy device 80x25 console [tty0] enabled Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory:
Re: commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 kills r8169 send performance
On Wed, Sep 26, 2007 at 09:52:02PM +0300, Timo Jantunen wrote: On Wed, 26 Sep 2007, Francois Romieu wrote: The patch below is scheduled for inclusion before 2.6.23. Please try it and see if it makes a difference on top of 2.6.23-rc8 (full dmesg will be welcome too). Thanks for the quick reply and fix. Unfortunately the fix didn't help in my case. In another thread on LKML today, there has been some discussion about a similar problem, which is caused by a locking bug in iperf which makes it spin at 100% CPU. Ingo has posted a fix for this, please check the list. Regards, Willy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 kills r8169 send performance
On Wed, 26 Sep 2007, Willy Tarreau wrote: On Wed, Sep 26, 2007 at 09:52:02PM +0300, Timo Jantunen wrote: On Wed, 26 Sep 2007, Francois Romieu wrote: The patch below is scheduled for inclusion before 2.6.23. Please try it and see if it makes a difference on top of 2.6.23-rc8 (full dmesg will be welcome too). Thanks for the quick reply and fix. Unfortunately the fix didn't help in my case. In another thread on LKML today, there has been some discussion about a similar problem, which is caused by a locking bug in iperf which makes it spin at 100% CPU. Ingo has posted a fix for this, please check the list. I noticed the problem originally with another program (playback of 720p video to remote X using mplayer). And in my case the CPU usage is 2-3% systime, 1% userspace so it doesn't seem to be anything to do with the scheduler (I did try that echo 1 /proc/sys/kernel/sched_compat_yield workaround, too.) //T Regards, Willy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 kills r8169 send performance
Timo Jantunen [EMAIL PROTECTED] : [...] Thanks for the quick reply and fix. Unfortunately the fix didn't help in my case. Apply and try each patch of the attached tarball on top of 2.6.23-git until the behavior changes (assuming it does). Patch #000n applies on top of patch #000(n - 1). Good night. -- Ueimor r8169-timo-20070926.tgz Description: GNU Zip compressed data
