1. 29 1月, 2008 1 次提交
  2. 07 11月, 2007 1 次提交
    • E
      [INET]: Remove per bucket rwlock in tcp/dccp ehash table. · 230140cf
      Eric Dumazet 提交于
      As done two years ago on IP route cache table (commit
      22c047cc) , we can avoid using one
      lock per hash bucket for the huge TCP/DCCP hash tables.
      
      On a typical x86_64 platform, this saves about 2MB or 4MB of ram, for
      litle performance differences. (we hit a different cache line for the
      rwlock, but then the bucket cache line have a better sharing factor
      among cpus, since we dirty it less often). For netstat or ss commands
      that want a full scan of hash table, we perform fewer memory accesses.
      
      Using a 'small' table of hashed rwlocks should be more than enough to
      provide correct SMP concurrency between different buckets, without
      using too much memory. Sizing of this table depends on
      num_possible_cpus() and various CONFIG settings.
      
      This patch provides some locking abstraction that may ease a future
      work using a different model for TCP/DCCP table.
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Acked-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      230140cf
  3. 30 10月, 2007 1 次提交
    • J
      [TCP]: Saner thash_entries default with much memory. · 0ccfe618
      Jean Delvare 提交于
      On systems with a very large amount of memory, the heuristics in
      alloc_large_system_hash() result in a very large TCP established hash
      table: 16 millions of entries for a 128 GB ia64 system. This makes
      reading from /proc/net/tcp pretty slow (well over a second) and as a
      result netstat is slow on these machines. I know that /proc/net/tcp is
      deprecated in favor of tcp_diag, however at the moment netstat only
      knows of the former.
      
      I am skeptical that such a large TCP established hash is often needed.
      Just because a system has a lot of memory doesn't imply that it will
      have several millions of concurrent TCP connections. Thus I believe
      that we should put an arbitrary high limit to the size of the TCP
      established hash by default. Users who really need a bigger hash can
      always use the thash_entries boot parameter to get more.
      
      I propose 2 millions of entries as the arbitrary high limit. This
      makes /proc/net/tcp reasonably fast on the system in question (0.2 s)
      while being still large enough for me to be confident that network
      performance won't suffer.
      
      This is just one way to limit the hash size, there are others; I am not
      familiar enough with the TCP code to decide which is best. Thus, I
      would welcome the proposals of alternatives.
      
      [ 2 million is still too large, thus I've modified the limit in the
        change to be '512 * 1024'. -DaveM ]
      Signed-off-by: NJean Delvare <jdelvare@suse.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0ccfe618
  4. 20 10月, 2007 1 次提交
  5. 11 10月, 2007 3 次提交
  6. 03 8月, 2007 1 次提交
    • D
      [TCP]: Invoke tcp_sendmsg() directly, do not use inet_sendmsg(). · 3516ffb0
      David S. Miller 提交于
      As discovered by Evegniy Polyakov, if we try to sendmsg after
      a connection reset, we can do incredibly stupid things.
      
      The core issue is that inet_sendmsg() tries to autobind the
      socket, but we should never do that for TCP.  Instead we should
      just go straight into TCP's sendmsg() code which will do all
      of the necessary state and pending socket error checks.
      
      TCP's sendpage already directly vectors to tcp_sendpage(), so this
      merely brings sendmsg() in line with that.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3516ffb0
  7. 20 7月, 2007 1 次提交
    • P
      mm: Remove slab destructors from kmem_cache_create(). · 20c2df83
      Paul Mundt 提交于
      Slab destructors were no longer supported after Christoph's
      c59def9f change. They've been
      BUGs for both slab and slub, and slob never supported them
      either.
      
      This rips out support for the dtor pointer from kmem_cache_create()
      completely and fixes up every single callsite in the kernel (there were
      about 224, not including the slab allocator definitions themselves,
      or the documentation references).
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      20c2df83
  8. 12 7月, 2007 2 次提交
  9. 24 6月, 2007 1 次提交
  10. 04 6月, 2007 1 次提交
  11. 31 5月, 2007 1 次提交
  12. 09 5月, 2007 1 次提交
  13. 04 5月, 2007 1 次提交
    • S
      [TCP]: zero out rx_opt in tcp_disconnect() · b40b4f79
      Srinivas Aji 提交于
      When the server drops its connection, NFS client reconnects using the
      same socket after disconnecting. If the new connection's SYN,ACK
      doesn't contain the TCP timestamp option and the old connection's did,
      tp->tcp_header_len is recomputed assuming no timestamp header but
      tp->rx_opt.tstamp_ok remains set. Then tcp_build_and_update_options()
      adds in a timestamp option past the end of the allocated TCP header,
      overwriting TCP data, or when the data is in skb_shinfo(skb)->frags[],
      overwriting skb_shinfo(skb) causing a crash soon after. (The issue was
      debugged from such a crash.)
      
      Similarly, wscale_ok and sack_ok also get set based on the SYN,ACK
      packet but not reset on disconnect, since they are zeroed out at
      initialization. The patch zeroes out the entire tp->rx_opt struct in
      tcp_disconnect() to avoid this sort of problem.
      Signed-off-by: NSrinivas Aji <Aji_Srinivas@emc.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b40b4f79
  14. 29 4月, 2007 1 次提交
  15. 26 4月, 2007 8 次提交
  16. 17 3月, 2007 1 次提交
  17. 27 2月, 2007 1 次提交
  18. 11 2月, 2007 1 次提交
  19. 09 2月, 2007 1 次提交
    • E
      [NET]: change layout of ehash table · dbca9b27
      Eric Dumazet 提交于
      ehash table layout is currently this one :
      
      First half of this table is used by sockets not in TIME_WAIT state
      Second half of it is used by sockets in TIME_WAIT state.
      
      This is non optimal because of for a given hash or socket, the two chain heads 
      are located in separate cache lines.
      Moreover the locks of the second half are never used.
      
      If instead of this halving, we use two list heads in inet_ehash_bucket instead 
      of only one, we probably can avoid one cache miss, and reduce ram usage, 
      particularly if sizeof(rwlock_t) is big (various CONFIG_DEBUG_SPINLOCK, 
      CONFIG_DEBUG_LOCK_ALLOC settings). So we still halves the table but we keep 
      together related chains to speedup lookups and socket state change.
      
      In this patch I did not try to align struct inet_ehash_bucket, but a future 
      patch could try to make this structure have a convenient size (a power of two 
      or a multiple of L1_CACHE_SIZE).
      I guess rwlock will just vanish as soon as RCU is plugged into ehash :) , so 
      maybe we dont need to scratch our heads to align the bucket...
      
      Note : In case struct inet_ehash_bucket is not a power of two, we could 
      probably change alloc_large_system_hash() (in case it use __get_free_pages()) 
      to free the unused space. It currently allocates a big zone, but the last 
      quarter of it could be freed. Again, this should be a temporary 'problem'.
      
      Patch tested on ipv4 tcp only, but should be OK for IPV6 and DCCP.
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dbca9b27
  20. 14 12月, 2006 1 次提交
  21. 03 12月, 2006 4 次提交
  22. 16 11月, 2006 1 次提交
  23. 08 11月, 2006 1 次提交
  24. 23 9月, 2006 4 次提交