1. 18 4月, 2011 1 次提交
  2. 17 4月, 2011 1 次提交
  3. 15 4月, 2011 3 次提交
  4. 05 4月, 2011 1 次提交
    • T
      net: Allow no-cache copy from user on transmit · c6e1a0d1
      Tom Herbert 提交于
      This patch uses __copy_from_user_nocache on transmit to bypass data
      cache for a performance improvement.  skb_add_data_nocache and
      skb_copy_to_page_nocache can be called by sendmsg functions to use
      this feature, initial support is in tcp_sendmsg.  This functionality is
      configurable per device using ethtool.
      
      Presumably, this feature would only be useful when the driver does
      not touch the data.  The feature is turned on by default if a device
      indicates that it does some form of checksum offload; it is off by
      default for devices that do no checksum offload or indicate no checksum
      is necessary.  For the former case copy-checksum is probably done
      anyway, in the latter case the device is likely loopback in which case
      the no cache copy is probably not beneficial.
      
      This patch was tested using 200 instances of netperf TCP_RR with
      1400 byte request and one byte reply.  Platform is 16 core AMD x86.
      
      No-cache copy disabled:
         672703 tps, 97.13% utilization
         50/90/99% latency:244.31 484.205 1028.41
      
      No-cache copy enabled:
         702113 tps, 96.16% utilization,
         50/90/99% latency 238.56 467.56 956.955
      
      Using 14000 byte request and response sizes demonstrate the
      effects more dramatically:
      
      No-cache copy disabled:
         79571 tps, 34.34 %utlization
         50/90/95% latency 1584.46 2319.59 5001.76
      
      No-cache copy enabled:
         83856 tps, 34.81% utilization
         50/90/95% latency 2508.42 2622.62 2735.88
      
      Note especially the effect on latency tail (95th percentile).
      
      This seems to provide a nice performance improvement and is
      consistent in the tests I ran.  Presumably, this would provide
      the greatest benfits in the presence of an application workload
      stressing the cache and a lot of transmit data happening.
      Signed-off-by: NTom Herbert <therbert@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c6e1a0d1
  5. 24 3月, 2011 1 次提交
  6. 20 3月, 2011 1 次提交
  7. 17 3月, 2011 6 次提交
  8. 16 3月, 2011 2 次提交
  9. 13 3月, 2011 1 次提交
  10. 10 3月, 2011 1 次提交
  11. 08 3月, 2011 2 次提交
  12. 03 3月, 2011 1 次提交
  13. 28 2月, 2011 3 次提交
  14. 14 2月, 2011 2 次提交
  15. 25 1月, 2011 2 次提交
  16. 21 1月, 2011 1 次提交
    • N
      bonding: Ensure that we unshare skbs prior to calling pskb_may_pull · b3053251
      Neil Horman 提交于
      Recently reported oops:
      
      kernel BUG at net/core/skbuff.c:813!
      invalid opcode: 0000 [#1] SMP
      last sysfs file: /sys/devices/virtual/net/bond0/broadcast
      CPU 8
      Modules linked in: sit tunnel4 cpufreq_ondemand acpi_cpufreq freq_table bonding
      ipv6 dm_mirror dm_region_hash dm_log cdc_ether usbnet mii serio_raw i2c_i801
      i2c_core iTCO_wdt iTCO_vendor_support shpchp ioatdma i7core_edac edac_core bnx2
      ixgbe dca mdio sg ext4 mbcache jbd2 sd_mod crc_t10dif mptsas mptscsih mptbase
      scsi_transport_sas dm_mod [last unloaded: microcode]
      
      Modules linked in: sit tunnel4 cpufreq_ondemand acpi_cpufreq freq_table bonding
      ipv6 dm_mirror dm_region_hash dm_log cdc_ether usbnet mii serio_raw i2c_i801
      i2c_core iTCO_wdt iTCO_vendor_support shpchp ioatdma i7core_edac edac_core bnx2
      ixgbe dca mdio sg ext4 mbcache jbd2 sd_mod crc_t10dif mptsas mptscsih mptbase
      scsi_transport_sas dm_mod [last unloaded: microcode]
      Pid: 0, comm: swapper Not tainted 2.6.32-71.el6.x86_64 #1 BladeCenter HS22
      -[7870AC1]-
      RIP: 0010:[<ffffffff81405b16>]  [<ffffffff81405b16>]
      pskb_expand_head+0x36/0x1e0
      RSP: 0018:ffff880028303b70  EFLAGS: 00010202
      RAX: 0000000000000002 RBX: ffff880c6458ec80 RCX: 0000000000000020
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880c6458ec80
      RBP: ffff880028303bc0 R08: ffffffff818a6180 R09: ffff880c6458ed64
      R10: ffff880c622b36c0 R11: 0000000000000400 R12: 0000000000000000
      R13: 0000000000000180 R14: ffff880c622b3000 R15: 0000000000000000
      FS:  0000000000000000(0000) GS:ffff880028300000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
      CR2: 00000038653452a4 CR3: 0000000001001000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process swapper (pid: 0, threadinfo ffff8806649c2000, task ffff880c64f16ab0)
      Stack:
       ffff880028303bc0 ffffffff8104fff9 000000000000001c 0000000100000000
      <0> ffff880000047d80 ffff880c6458ec80 000000000000001c ffff880c6223da00
      <0> ffff880c622b3000 0000000000000000 ffff880028303c10 ffffffff81407f7a
      Call Trace:
      <IRQ>
       [<ffffffff8104fff9>] ? __wake_up_common+0x59/0x90
       [<ffffffff81407f7a>] __pskb_pull_tail+0x2aa/0x360
       [<ffffffffa0244530>] bond_arp_rcv+0x2c0/0x2e0 [bonding]
       [<ffffffff814a0857>] ? packet_rcv+0x377/0x440
       [<ffffffff8140f21b>] netif_receive_skb+0x2db/0x670
       [<ffffffff8140f788>] napi_skb_finish+0x58/0x70
       [<ffffffff8140fc89>] napi_gro_receive+0x39/0x50
       [<ffffffffa01286eb>] ixgbe_clean_rx_irq+0x35b/0x900 [ixgbe]
       [<ffffffffa01290f6>] ixgbe_clean_rxtx_many+0x136/0x240 [ixgbe]
       [<ffffffff8140fe53>] net_rx_action+0x103/0x210
       [<ffffffff81073bd7>] __do_softirq+0xb7/0x1e0
       [<ffffffff810d8740>] ? handle_IRQ_event+0x60/0x170
       [<ffffffff810142cc>] call_softirq+0x1c/0x30
       [<ffffffff81015f35>] do_softirq+0x65/0xa0
       [<ffffffff810739d5>] irq_exit+0x85/0x90
       [<ffffffff814cf915>] do_IRQ+0x75/0xf0
       [<ffffffff81013ad3>] ret_from_intr+0x0/0x11
       <EOI>
       [<ffffffff8101bc01>] ? mwait_idle+0x71/0xd0
       [<ffffffff814cd80a>] ? atomic_notifier_call_chain+0x1a/0x20
       [<ffffffff81011e96>] cpu_idle+0xb6/0x110
       [<ffffffff814c17c8>] start_secondary+0x1fc/0x23f
      
      Resulted from bonding driver registering packet handlers via dev_add_pack and
      then trying to call pskb_may_pull. If another packet handler (like for AF_PACKET
      sockets) gets called first, the delivered skb will have a user count > 1, which
      causes pskb_may_pull to BUG halt when it does its skb_shared check.  Fix this by
      calling skb_share_check prior to the may_pull call sites in the bonding driver
      to clone the skb when needed.  Tested by myself and the reported successfully.
      
      Signed-off-by: Neil Horman
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NAndy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b3053251
  17. 17 12月, 2010 2 次提交
  18. 11 12月, 2010 1 次提交
  19. 10 12月, 2010 1 次提交
    • N
      net: Convert netpoll blocking api in bonding driver to be a counter · fb4fa76a
      Neil Horman 提交于
      A while back I made some changes to enable netpoll in the bonding driver.  Among
      them was a per-cpu flag that indicated we were in a path that held locks which
      could cause the netpoll path to block in during tx, and as such the tx path
      should queue the frame for later use.  This appears to have given rise to a
      regression.  If one of those paths on which we hold the per-cpu flag yields the
      cpu, its possible for us to come back on a different cpu, leading to us clearing
      a different flag than we set.  This results in odd netpoll drops, and BUG
      backtraces appearing in the log, as we check to make sure that we only clear set
      bits, and only set clear bits.  I had though briefly about changing the
      offending paths so that they wouldn't sleep, but looking at my origional work
      more closely, it doesn't appear that a per-cpu flag is warranted.  We alrady
      gate the checking of this flag on IFF_IN_NETPOLL, so we don't hit this in the
      normal tx case anyway.  And practically speaking, the normal use case for
      netpoll is to only have one client anyway, so we're not going to erroneously
      queue netpoll frames when its actually safe to do so.  As such, lets just
      convert that per-cpu flag to an atomic counter.  It fixes the rescheduling bugs,
      is equivalent from a performance perspective and actually eliminates some code
      in the process.
      
      Tested by the reporter and myself, successfully
      Reported-by: NLiang Zheng <lzheng@redhat.com>
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: David S. Miller <davem@davemloft.net>
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fb4fa76a
  20. 02 12月, 2010 1 次提交
  21. 19 11月, 2010 2 次提交
  22. 09 11月, 2010 1 次提交
  23. 28 10月, 2010 1 次提交
    • J
      bonding: Fix lockdep warning after bond_vlan_rx_register() · a71fb881
      Jarek Poplawski 提交于
      Fix lockdep warning:
      [   52.991402] ======================================================
      [   52.991511] [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]
      [   52.991569] 2.6.36-04573-g4b60626-dirty #65
      [   52.991622] ------------------------------------------------------
      [   52.991696] ip/4842 [HC0[0]:SC0[4]:HE1:SE0] is trying to acquire:
      [   52.991758]  (&bond->lock){++++..}, at: [<efe4d300>] bond_set_multicast_list+0x60/0x2c0 [bonding]
      [   52.991966]
      [   52.991967] and this task is already holding:
      [   52.992008]  (&bonding_netdev_addr_lock_key){+.....}, at: [<c04e5530>] dev_mc_sync+0x50/0xa0
      [   52.992008] which would create a new lock dependency:
      [   52.992008]  (&bonding_netdev_addr_lock_key){+.....} -> (&bond->lock){++++..}
      [   52.992008]
      [   52.992008] but this new dependency connects a SOFTIRQ-irq-safe lock:
      [   52.992008]  (&(&mc->mca_lock)->rlock){+.-...}
      [   52.992008] ... which became SOFTIRQ-irq-safe at:
      [   52.992008]   [<c0272beb>] __lock_acquire+0x96b/0x1960
      [   52.992008]   [<c027415e>] lock_acquire+0x7e/0xf0
      [   52.992008]   [<c05f356d>] _raw_spin_lock_bh+0x3d/0x50
      [   52.992008]   [<c0584e40>] mld_ifc_timer_expire+0xf0/0x280
      [   52.992008]   [<c024cee6>] run_timer_softirq+0x146/0x310
      [   52.992008]   [<c024591d>] __do_softirq+0xad/0x1c0
      [   52.992008]
      [   52.992008] to a SOFTIRQ-irq-unsafe lock:
      [   52.992008]  (&bond->lock){++++..}
      [   52.992008] ... which became SOFTIRQ-irq-unsafe at:
      [   52.992008] ...  [<c0272c3b>] __lock_acquire+0x9bb/0x1960
      [   52.992008]   [<c027415e>] lock_acquire+0x7e/0xf0
      [   52.992008]   [<c05f36b8>] _raw_write_lock+0x38/0x50
      [   52.992008]   [<efe4cbe4>] bond_vlan_rx_register+0x24/0x70 [bonding]
      [   52.992008]   [<c0598010>] register_vlan_dev+0xc0/0x280
      [   52.992008]   [<c0599f3a>] vlan_newlink+0xaa/0xd0
      [   52.992008]   [<c04ed4b4>] rtnl_newlink+0x404/0x490
      [   52.992008]   [<c04ece35>] rtnetlink_rcv_msg+0x1e5/0x220
      [   52.992008]   [<c050424e>] netlink_rcv_skb+0x8e/0xb0
      [   52.992008]   [<c04ecbac>] rtnetlink_rcv+0x1c/0x30
      [   52.992008]   [<c0503bfb>] netlink_unicast+0x24b/0x290
      [   52.992008]   [<c0503e37>] netlink_sendmsg+0x1f7/0x310
      [   52.992008]   [<c04cd41c>] sock_sendmsg+0xac/0xe0
      [   52.992008]   [<c04ceb80>] sys_sendmsg+0x130/0x230
      [   52.992008]   [<c04cf04e>] sys_socketcall+0xde/0x280
      [   52.992008]   [<c0202d10>] sysenter_do_call+0x12/0x36
      [   52.992008]
      [   52.992008] other info that might help us debug this:
      ...
      [ Full info at netdev: Wed, 27 Oct 2010 12:24:30 +0200
        Subject: [BUG net-2.6 vlan/bonding] lockdep splats ]
      
      Use BH variant of write_lock(&bond->lock) (as elsewhere in bond_main)
      to prevent this dependency.
      
      Fixes commit f35188fa [v2.6.36]
      Reported-by: NEric Dumazet <eric.dumazet@gmail.com>
      Tested-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NJarek Poplawski <jarkao2@gmail.com>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Cc: Jay Vosburgh <fubar@us.ibm.com>
      a71fb881
  24. 21 10月, 2010 2 次提交