1. 17 11月, 2008 1 次提交
    • B
      ipv4: Fix ARP behavior with many mac-vlans · 8164f1b7
      Ben Greear 提交于
      Ben Greear wrote:
      > I have 500 mac-vlans on a system talking to 500 other
      > mac-vlans.  My problem is that the arp-table gets extremely
      > huge because every time an arp-request comes in on all mac-vlans,
      > a stale arp entry is added for each mac-vlan.  I have filtering
      > turned on, but that doesn't help because the neigh_event_ns call
      > below will cause a stale neighbor entry to be created regardless
      > of whether a replay will be sent or not.
      > Maybe the neigh_event code should be below the checks for dont_send,
      > and only create check neigh_event_ns if we are !dont_send?
      
      The attached patch makes it work much better for me.  The patch
      will cause the code to NOT create a stale neighbor entry if we
      are not going to respond to the ARP request.  The old code
      *would* create a stale entry even if we are not going to respond.
      Signed-off-by: NBen Greear <greearb@candelatech.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8164f1b7
  2. 14 11月, 2008 2 次提交
    • E
      net: speedup dst_release() · ef711cf1
      Eric Dumazet 提交于
      During tbench/oprofile sessions, I found that dst_release() was in third position.
      
      CPU: Core 2, speed 2999.68 MHz (estimated)
      Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000
      samples  %        symbol name
      483726    9.0185  __copy_user_zeroing_intel
      191466    3.5697  __copy_user_intel
      185475    3.4580  dst_release
      175114    3.2648  ip_queue_xmit
      153447    2.8608  tcp_sendmsg
      108775    2.0280  tcp_recvmsg
      102659    1.9140  sysenter_past_esp
      101450    1.8914  tcp_current_mss
      95067     1.7724  __copy_from_user_ll
      86531     1.6133  tcp_transmit_skb
      
      Of course, all CPUS fight on the dst_entry associated with 127.0.0.1 
      
      Instead of first checking the refcount value, then decrement it,
      we use atomic_dec_return() to help CPU to make the right memory transaction
      (ie getting the cache line in exclusive mode)
      
      dst_release() is now at the fifth position, and tbench a litle bit faster ;)
      
      CPU: Core 2, speed 3000.1 MHz (estimated)
      Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000
      samples  %        symbol name
      647107    8.8072  __copy_user_zeroing_intel
      258840    3.5229  ip_queue_xmit
      258302    3.5155  __copy_user_intel
      209629    2.8531  tcp_sendmsg
      165632    2.2543  dst_release
      149232    2.0311  tcp_current_mss
      147821    2.0119  tcp_recvmsg
      137893    1.8767  sysenter_past_esp
      127473    1.7349  __copy_from_user_ll
      121308    1.6510  ip_finish_output
      118510    1.6129  tcp_transmit_skb
      109295    1.4875  tcp_v4_rcv
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ef711cf1
    • J
      pkt_sched: Remove qdisc->ops->requeue() etc. · f30ab418
      Jarek Poplawski 提交于
      After implementing qdisc->ops->peek() and changing sch_netem into
      classless qdisc there are no more qdisc->ops->requeue() users. This
      patch removes this method with its wrappers (qdisc_requeue()), and
      also unused qdisc->requeue structure. There are a few minor fixes of
      warnings (htb_enqueue()) and comments btw.
      
      The idea to kill ->requeue() and a similar patch were first developed
      by David S. Miller.
      Signed-off-by: NJarek Poplawski <jarkao2@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f30ab418
  3. 13 11月, 2008 2 次提交
  4. 12 11月, 2008 8 次提交
  5. 11 11月, 2008 25 次提交
  6. 10 11月, 2008 1 次提交
    • M
      net: unix: fix inflight counting bug in garbage collector · 6209344f
      Miklos Szeredi 提交于
      Previously I assumed that the receive queues of candidates don't
      change during the GC.  This is only half true, nothing can be received
      from the queues (see comment in unix_gc()), but buffers could be added
      through the other half of the socket pair, which may still have file
      descriptors referring to it.
      
      This can result in inc_inflight_move_tail() erronously increasing the
      "inflight" counter for a unix socket for which dec_inflight() wasn't
      previously called.  This in turn can trigger the "BUG_ON(total_refs <
      inflight_refs)" in a later garbage collection run.
      
      Fix this by only manipulating the "inflight" counter for sockets which
      are candidates themselves.  Duplicating the file references in
      unix_attach_fds() is also needed to prevent a socket becoming a
      candidate for GC while the skb that contains it is not yet queued.
      Reported-by: NAndrea Bittau <a.bittau@cs.ucl.ac.uk>
      Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>
      CC: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6209344f
  7. 08 11月, 2008 1 次提交