On Thu, Mar 09, 2006 at 01:18:26PM +0300, Evgeniy Polyakov wrote:
Ok, I hacked quite a bit in the patch, but I think nothing major was
changed, basically patch rejects.
And I'm now unable to bind to 0.0.0.0 address, i.e. bind() does not
fail, but all connections are refused.
Bind to machine's
Benjamin LaHaise a écrit :
Hello again,
This patch introduces the use of rcu for the ipv4 established connections
hashtable, as well as the timewait table since they are closely intertwined.
This removes 4 atomic operations per packet from the tcp_v4_rcv codepath,
which helps quite a bit
On a second thought, do you think we still need one rwlock per hash chain ?
TCP established hash table entries: 1048576 (order: 12, 16777216 bytes)
On this x86_64 machine, we 'waste' 8 MB of ram for those rwlocks.
With RCU, we touch these rwlocks only on TCP connection
creation/deletion,
On Thu, Mar 09, 2006 at 09:43:00AM -0800, Benjamin LaHaise ([EMAIL PROTECTED])
wrote:
On Thu, Mar 09, 2006 at 01:18:26PM +0300, Evgeniy Polyakov wrote:
Ok, I hacked quite a bit in the patch, but I think nothing major was
changed, basically patch rejects.
And I'm now unable to bind to
Rick Jones a écrit :
On a second thought, do you think we still need one rwlock per hash
chain ?
TCP established hash table entries: 1048576 (order: 12, 16777216 bytes)
On this x86_64 machine, we 'waste' 8 MB of ram for those rwlocks.
With RCU, we touch these rwlocks only on TCP
On Thu, Mar 09, 2006 at 07:25:25PM +0100, Eric Dumazet wrote:
On a second thought, do you think we still need one rwlock per hash chain ?
TCP established hash table entries: 1048576 (order: 12, 16777216 bytes)
On this x86_64 machine, we 'waste' 8 MB of ram for those rwlocks.
With RCU, we
From: Benjamin LaHaise [EMAIL PROTECTED]
Date: Thu, 9 Mar 2006 12:50:44 -0800
Hrm, maybe use cmpxchg? That gets rid of the lock and automatically
provides us with hashed spinlocks on archs without a cmpxchg
implementation.
I don't think we even need to go there, here's why.
Once we have RCU
From: Eric Dumazet [EMAIL PROTECTED]
Date: Thu, 09 Mar 2006 20:32:16 +0100
#define PTRS_PER_CACHELINE ((L1_CACHE_BYTES - sizeof(rwlock_t))/sizeof(struct
hlist_head))
struct hash_agg_bucket {
rwlock_t wlock;
struct hlist_head chains[PTRS_PER_CACHELINE];
};
A division by a
On Thu, Mar 09, 2006 at 01:12:20PM -0800, David S. Miller wrote:
Once we have RCU in place for the TCP hash tables, we have the chance
to code up dynamically sized hash tables. With the current locking,
this is basically impossible, with RCU it can be done.
Nice!
So Ben can you work to
From: Benjamin LaHaise [EMAIL PROTECTED]
Date: Thu, 9 Mar 2006 13:35:16 -0800
On Thu, Mar 09, 2006 at 01:12:20PM -0800, David S. Miller wrote:
So Ben can you work to figure out what the bind(0.0.0.0)
problem was? Once that is fully resolved, I think I'll apply
your RCU patch to
On Tue, Mar 07, 2006 at 03:03:13PM -0800, David S. Miller ([EMAIL PROTECTED])
wrote:
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Wed, 8 Mar 2006 00:51:33 +0300
RCU introduces noticeble latencies for writing part compared to
rwlock, so workloads when a lot of new short connections are
On Wed, Mar 08, 2006 at 02:01:04PM +0300, Evgeniy Polyakov wrote:
When I tested RCU for similar change for kevent, but postponed more work
to RCU callback, including socket closing and some attempts to inode
dereferencing, such change forced performance degradation for httperf
benchmark and
On Mon, Mar 06, 2006 at 02:01:11PM -0800, Benjamin LaHaise ([EMAIL PROTECTED])
wrote:
Hello again,
This patch introduces the use of rcu for the ipv4 established connections
hashtable, as well as the timewait table since they are closely intertwined.
This removes 4 atomic operations per
Hello again,
This patch introduces the use of rcu for the ipv4 established connections
hashtable, as well as the timewait table since they are closely intertwined.
This removes 4 atomic operations per packet from the tcp_v4_rcv codepath,
which helps quite a bit when the other performance
From: Benjamin LaHaise [EMAIL PROTECTED]
Date: Mon, 6 Mar 2006 14:01:11 -0800
This patch introduces the use of rcu for the ipv4 established
connections hashtable, as well as the timewait table since they are
closely intertwined.
Thanks for doing this work, I'll try study it seriously very
Benjamin LaHaise a écrit :
Hello again,
This patch introduces the use of rcu for the ipv4 established connections
hashtable, as well as the timewait table since they are closely intertwined.
This removes 4 atomic operations per packet from the tcp_v4_rcv codepath,
which helps quite a bit
On Tue, Mar 07, 2006 at 12:48:23AM +0100, Eric Dumazet wrote:
If I understand your patch correctly, your future plan is to change struct
inet_ehash_bucket rwlock_t wlock to a pure spinlock (when ipv6 is
converted to rcu lookups too), because no more read_lock() are expected ?
Yes/no... The
17 matches
Mail list logo
