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: 2072204k
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
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 :...::
