1. 15 4月, 2015 38 次提交
  2. 14 4月, 2015 2 次提交
    • D
      Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs · 6e8a9d91
      David S. Miller 提交于
      Al Viro says:
      
      ====================
      netdev-related stuff in vfs.git
      
      There are several commits sitting in vfs.git that probably ought to go in
      via net-next.git.  First of all, there's merge with vfs.git#iocb - that's
      Christoph's aio rework, which has triggered conflicts with the ->sendmsg()
      and ->recvmsg() patches a while ago.  It's not so much Christoph's stuff
      that ought to be in net-next, as (pretty simple) conflict resolution on merge.
      The next chunk is switch to {compat_,}import_iovec/import_single_range - new
      safer primitives for initializing iov_iter.  The primitives themselves come
      from vfs/git#iov_iter (and they are used quite a lot in vfs part of queue),
      conversion of net/socket.c syscalls belongs in net-next, IMO.  Next there's
      afs and rxrpc stuff from dhowells.  And then there's sanitizing kernel_sendmsg
      et.al.  + missing inlined helper for "how much data is left in msg->msg_iter" -
      this stuff is used in e.g.  cifs stuff, but it belongs in net-next.
      
      That pile is pullable from
      git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-davem
      
      I'll post the individual patches in there in followups; could you take a look
      and tell if everything in there is OK with you?
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6e8a9d91
    • E
      tcp/dccp: get rid of central timewait timer · 789f558c
      Eric Dumazet 提交于
      Using a timer wheel for timewait sockets was nice ~15 years ago when
      memory was expensive and machines had a single processor.
      
      This does not scale, code is ugly and source of huge latencies
      (Typically 30 ms have been seen, cpus spinning on death_lock spinlock.)
      
      We can afford to use an extra 64 bytes per timewait sock and spread
      timewait load to all cpus to have better behavior.
      
      Tested:
      
      On following test, /proc/sys/net/ipv4/tcp_tw_recycle is set to 1
      on the target (lpaa24)
      
      Before patch :
      
      lpaa23:~# ./super_netperf 200 -H lpaa24 -t TCP_CC -l 60 -- -p0,0
      419594
      
      lpaa23:~# ./super_netperf 200 -H lpaa24 -t TCP_CC -l 60 -- -p0,0
      437171
      
      While test is running, we can observe 25 or even 33 ms latencies.
      
      lpaa24:~# ping -c 1000 -i 0.02 -qn lpaa23
      ...
      1000 packets transmitted, 1000 received, 0% packet loss, time 20601ms
      rtt min/avg/max/mdev = 0.020/0.217/25.771/1.535 ms, pipe 2
      
      lpaa24:~# ping -c 1000 -i 0.02 -qn lpaa23
      ...
      1000 packets transmitted, 1000 received, 0% packet loss, time 20702ms
      rtt min/avg/max/mdev = 0.019/0.183/33.761/1.441 ms, pipe 2
      
      After patch :
      
      About 90% increase of throughput :
      
      lpaa23:~# ./super_netperf 200 -H lpaa24 -t TCP_CC -l 60 -- -p0,0
      810442
      
      lpaa23:~# ./super_netperf 200 -H lpaa24 -t TCP_CC -l 60 -- -p0,0
      800992
      
      And latencies are kept to minimal values during this load, even
      if network utilization is 90% higher :
      
      lpaa24:~# ping -c 1000 -i 0.02 -qn lpaa23
      ...
      1000 packets transmitted, 1000 received, 0% packet loss, time 19991ms
      rtt min/avg/max/mdev = 0.023/0.064/0.360/0.042 ms
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      789f558c