Date: Sat, 07 Jan 2006 00:36:25 -0800 (PST)
Message-Id: <20060107.003625.50986701.davem@davemloft.net>
To: dada1@cosmosbay.com
Cc: ak@suse.de, paulmck@us.ibm.com, alan@lxorguk.ukuu.org.uk,
       torvalds@osdl.org, linux-kernel@vger.kernel.org, dipankar@in.ibm.com,
       manfred@colorfullife.com, netdev@vger.kernel.org
Subject: Re: [PATCH, RFC] RCU : OOM avoidance and lower latency
From: "David S. Miller" <davem@davemloft.net>
In-Reply-To: <43BF7390.6050005@cosmosbay.com>
References: <43BF6F0B.4060108@cosmosbay.com>
	<20060106.234440.53993868.davem@davemloft.net>
	<43BF7390.6050005@cosmosbay.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1658
Lines: 42

From: Eric Dumazet <dada1@cosmosbay.com>
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 this single
> spinlock patch.  How is it supposed to help the 'ip route flush
> cache' problem ?  In my case, I have about 600.000 dst-entries :

I don't claim to have a solution to this problem currently.

Doing RCU and going through the whole DST GC machinery is overkill for
an active system.  So, perhaps a very simple solution will do:

1) On rt_run_flush(), do not rt_free(), instead collect all active
   routing cache entries onto a global list, begin a timer to
   fire in 10 seconds (or some sysctl configurable amount).

2) When a new routing cache entry is needed, check the global
   list appended to in #1 above first, failing that do dst_alloc()
   as is done currently.

3) If timer expires, rt_free() any entries in the global list.

The missing trick is how to ensure RCU semantics when reallocating
from the global list.

The idea is that an active system will immediately repopulate itself
with all of these entries just flushed from the table.

RCU really doesn't handle this kind of problem very well.  It truly
excels when work is generated by process context work, not interrupt
work.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/