On Fri, Jan 19, 2001 at 12:14:53AM +0100, Andi Kleen wrote:
> 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]
I really like this argument. Lets use it this way:
Why we need swaping in the kernel? Has there been any real world problem
shown that cannot be solved by adding few more MB of memory into the box?
:)
The point is we can enlarge netlink queue by factor of 20 without increasing
buffer size.
>
> Shared memory IMHO is an option for a local hack for some routing appliance,
> it shouldn't be in the main kernel.
>
Agreed.
>
> -Andi
>
> --
> This is like TV. I don't like TV.
--
Gleb.
|