summaryrefslogtreecommitdiff
path: root/net/tipc
diff options
context:
space:
mode:
authorEric Dumazet <dada1@cosmosbay.com>2007-02-09 01:16:46 +0300
committerDavid S. Miller <davem@davemloft.net>2007-02-09 01:16:46 +0300
commitdbca9b2750e3b1ee6f56a616160ccfc12e8b161f (patch)
treebf84c0acb5495fc95bc616d32b8af946f2e3bca9 /net/tipc
parenteac3731bd04c7131478722a3c148b78774553116 (diff)
downloadlinux-dbca9b2750e3b1ee6f56a616160ccfc12e8b161f.tar.xz
[NET]: change layout of ehash table
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: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/tipc')
0 files changed, 0 insertions, 0 deletions