David S. Miller a écrit :
Eric, how important do you honestly think the per-hashchain spinlocks
are? That's the big barrier from making rt_secret_rebuild() a simple
rehash instead of flushing the whole table as it does now.
No problem for me in going to a single spinlock.
I did the hashed
From: Eric Dumazet [EMAIL PROTECTED]
Date: Sat, 07 Jan 2006 08:53:52 +0100
I have no problem with this, since the biggest server I have is 4
way, but are you sure big machines wont suffer from this single
spinlock ?
It is the main question.
Also I dont understand what you want to do after
On Sat, Jan 07, 2006 at 12:36:25AM -0800, David S. Miller wrote:
From: Eric Dumazet [EMAIL PROTECTED]
Date: Sat, 07 Jan 2006 08:53:52 +0100
I have no problem with this, since the biggest server I have is 4
way, but are you sure big machines wont suffer from this single
spinlock ?
It
First patch was buggy, sorry :(
This 2nd version makes no more RCU assumptions, because only the 'donelist'
queue is fetched for an item to be deleted. Items from the donelist are ready
to be freed.
This V2 also corrects a problem in case of a CPU hotplug, we forgot to update
the -count
On Friday 06 January 2006 11:17, Eric Dumazet wrote:
I assume that if a CPU queued 10.000 items in its RCU queue, then the
oldest entry cannot still be in use by another CPU. This might sounds as a
violation of RCU rules, (I'm not an RCU expert) but seems quite reasonable.
I don't think it's
Andi Kleen a écrit :
On Friday 06 January 2006 11:17, Eric Dumazet wrote:
I assume that if a CPU queued 10.000 items in its RCU queue, then the
oldest entry cannot still be in use by another CPU. This might sounds as a
violation of RCU rules, (I'm not an RCU expert) but seems quite reasonable.
Alan Cox a écrit :
On Gwe, 2006-01-06 at 11:17 +0100, Eric Dumazet wrote:
I assume that if a CPU queued 10.000 items in its RCU queue, then the oldest
entry cannot still be in use by another CPU. This might sounds as a violation
of RCU rules, (I'm not an RCU expert) but seems quite reasonable.
On Gwe, 2006-01-06 at 15:00 +0100, Eric Dumazet wrote:
In the case of call_rcu_bh(), you can be sure that the caller cannot afford
'sleeping memory allocations'. Better drop a frame than block the stack, no ?
atomic allocations can't sleep and will fail which is fine. If memory
allocation
On Fri, Jan 06, 2006 at 01:37:12PM +, Alan Cox wrote:
On Gwe, 2006-01-06 at 11:17 +0100, Eric Dumazet wrote:
I assume that if a CPU queued 10.000 items in its RCU queue, then the
oldest
entry cannot still be in use by another CPU. This might sounds as a
violation
of RCU rules,
Paul E. McKenney a écrit :
On Fri, Jan 06, 2006 at 01:37:12PM +, Alan Cox wrote:
On Gwe, 2006-01-06 at 11:17 +0100, Eric Dumazet wrote:
I assume that if a CPU queued 10.000 items in its RCU queue, then the oldest
entry cannot still be in use by another CPU. This might sounds as a violation
On Fri, 2006-01-06 at 13:58 +0100, Andi Kleen wrote:
Another CPU might be stuck in a long
running interrupt
Shouldn't a long running interrupt be considered a bug?
Lee
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More
On Fri, 2006-01-06 at 11:17 +0100, Eric Dumazet wrote:
I have some servers that once in a while crashes when the ip route
cache is flushed. After
raising /proc/sys/net/ipv4/route/secret_interval (so that *no*
flush is done), I got better uptime for these servers.
Argh, where is that
On Fri, Jan 06, 2006 at 06:19:15PM +0100, Eric Dumazet wrote:
Paul E. McKenney a écrit :
On Fri, Jan 06, 2006 at 01:37:12PM +, Alan Cox wrote:
On Gwe, 2006-01-06 at 11:17 +0100, Eric Dumazet wrote:
I assume that if a CPU queued 10.000 items in its RCU queue, then the
oldest entry cannot
On Saturday 07 January 2006 01:17, David S. Miller wrote:
I mean something like this patch:
Looks like a good idea to me.
I always disliked the per chain spinlocks even for other hash tables like
TCP/UDP multiplex - it would be much nicer to use a much smaller separately
hashed lock table
From: Andi Kleen [EMAIL PROTECTED]
Date: Sat, 7 Jan 2006 02:09:01 +0100
I always disliked the per chain spinlocks even for other hash tables like
TCP/UDP multiplex - it would be much nicer to use a much smaller separately
hashed lock table and save cache. In this case the special case of
Andi Kleen a écrit :
I always disliked the per chain spinlocks even for other hash tables like
TCP/UDP multiplex - it would be much nicer to use a much smaller separately
hashed lock table and save cache. In this case the special case of using
a one entry only lock hash table makes sense.
From: Eric Dumazet [EMAIL PROTECTED]
Date: Sat, 07 Jan 2006 08:34:35 +0100
I agree, I do use a hashed spinlock array on my local tree for TCP,
mainly to reduce the hash table size by a 2 factor.
So what do you think about going to a single spinlock for the
routing cache?
-
To unsubscribe from
David S. Miller a écrit :
From: Eric Dumazet [EMAIL PROTECTED]
Date: Sat, 07 Jan 2006 08:34:35 +0100
I agree, I do use a hashed spinlock array on my local tree for TCP,
mainly to reduce the hash table size by a 2 factor.
So what do you think about going to a single spinlock for the
routing
18 matches
Mail list logo
