On Thu, Jan 18, 2001 at 10:48:18PM +0100, Benjamin C.R. LaHaise wrote:
> On Thu, 18 Jan 2001, Andi Kleen wrote:
>
> > It is when you go to "dump netlink state every 60s" mode on overload.
>
> 60 esconds is way too long, but arguing about the length of polls isn't a
> useful way to solve the problem. A good example for the characteristics
> needed comes from the typical ISP setting. If an L2TP server goes down
> for whatever reason and eventually comes back up, the system ends up with
> several thousand users, perhaps tens of thousands, all reconnecting within
> the same 3 second interval. If the connection takes more than a few
> seconds to come up, then the user will disconnect and attempt to
> reconnect -- presenting a further overload on the system (this is a real
> world example a local ISP has encountered).
>
> So far the shared memory idea sounds like it holds the most promise. I
> could see having a series of device ids, states and generation #'s would
> make the whole thing very efficient for both small and large state
> changes.
Somehow this thread looks like Don Quichote chasing wind mills for me @)
Has there been any real world problem shown that cannot be solved by
increasing the netlink queue to a few MB? [the default of 64K arguably
is a bit on the low side]
Shared memory IMHO is an option for a local hack for some routing appliance,
it shouldn't be in the main kernel.
-Andi
--
This is like TV. I don't like TV.
|