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 ne
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 f
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 divi
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
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 R
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 connectio
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
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, m
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 whe
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 machi
On Wed, Mar 08, 2006 at 09:11:49AM -0800, Benjamin LaHaise ([EMAIL PROTECTED])
wrote:
> 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
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 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 connectio
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 created
> and destroyed, like busy web server within LAN with small latencies,
> will suf
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 p
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... T
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 whe
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
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 barri
19 matches
Mail list logo
