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
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 af
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 sp
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
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 fr
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.
I
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
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: Fri, 6 Jan 2006 21:57:41 +0100
> Perhaps a better way would be to just exclude dst entries in RCU state
> from the normal accounting and assume that if the system
> really runs short of memory because of this the results would
> trigger quiescent states m
On Friday 06 January 2006 20:26, Lee Revell wrote:
> 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?
In normal operation yes, but there can be always exceptional
circum
On Friday 06 January 2006 21:26, Paul E. McKenney wrote:
> If not, it may be worthwhile to limit the number of times that
> rt_run_flush() runs per RCU grace period.
Problem is that without rt_run_flush new routes and route attribute
changes don't get used by the stack. If RCU takes long and rout
From: "Paul E. McKenney" <[EMAIL PROTECTED]>
Date: Fri, 6 Jan 2006 12:26:26 -0800
> If not, it may be worthwhile to limit the number of times that
> rt_run_flush() runs per RCU grace period.
This is mixing two sets of requirements.
rt_run_flush() runs periodically in order to regenerate the hash
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
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 docu
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 majo
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, 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 RC
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 pre
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 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.
Fixing the rea
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.
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 i
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 var
In order to avoid some OOM triggered by a flood of call_rcu() calls, we
increased in linux 2.6.14 maxbatch from 10 to 1, and conditionally call
set_need_resched() in call_rcu().
This solution doesnt solve all the problems and has drawbacks.
1) Using a big maxbatch has a bad impact on lat
24 matches
Mail list logo
