1. 11 10月, 2007 1 次提交
  2. 13 2月, 2007 1 次提交
  3. 11 2月, 2007 1 次提交
  4. 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
  5. 03 12月, 2006 1 次提交
  6. 29 9月, 2006 1 次提交
    • A
      [IPV4]: INET_MATCH() annotations · 4f765d84
      Al Viro 提交于
      INET_MATCH() and friends depend on an interesting set of kludges:
      	* there's a pair of adjacent fields in struct inet_sock - __be16 dport
      followed by __u16 num.  We want to search by pair, so we combine the keys into
      a single 32bit value and compare with 32bit value read from &...->dport.
      	* on 64bit targets we combine comparisons with pair of adjacent __be32
      fields in the same way.
      
      Make sure that we don't mix those values with anything else and that pairs
      we form them from have correct types.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4f765d84
  7. 01 7月, 2006 1 次提交
  8. 10 4月, 2006 1 次提交
  9. 14 3月, 2006 1 次提交
  10. 04 1月, 2006 1 次提交
  11. 30 8月, 2005 1 次提交