[RFC] kern/kern_timeout.c rewrite in progress

[Slawa Olhovchenkov]

On Thu, Jan 15, 2015 at 05:42:36PM +0100, Hans Petter Selasky wrote:

> On 01/15/15 16:58, Slawa Olhovchenkov wrote:
> > On Thu, Jan 15, 2015 at 04:51:00PM +0100, Hans Petter Selasky wrote:
> >
> >> On 01/15/15 16:46, Slawa Olhovchenkov wrote:
> >>> On Thu, Jan 15, 2015 at 04:37:51PM +0100, Hans Petter Selasky wrote:
> >>>
> >>> Only stability impovement?
> >>> Or performance too?
> >>
> >> Hi,
> >>
> >> Stability improvement mostly. Should not affect performance from what I
> >> know. Some changes are made about when and how we can select a different
> >> callback CPU for a callout callback. Try reading the updated timeout(9)
> >
> > I am not kernel guru and can't be draw a conclusion from manual page.
> >
> >> man manual page first. Maybe it answers your question. Else feel free to
> >> ask here.
> >
> > As I understand performance for massive TCP connections (tens of
> > thousands connections) will be same, no improvement, no degraded?
> > (very high lock congestion on TCP timers working).
> 
> Hi,
> 
> There is no difference in memory footprint per TCP connection.
> 
> There is no significant different in the amount of code executed when a 
> callout is started/stopped or reset.
> 
> There might be a reduction in the number of times the spinlocks inside 
> the callout subsystem are locked/unlocked, due to some simplifications 
> made and checks for redundant locking.
> 
> The changes are mainly about closing some races in the callout subsystem 
> and cornercases towards the TCP/IP stack which use callouts.
> 
> There is a patch for the TCP/IP stack coming possibly next week to take 
> advantage of the new callout_drain_async() function. It is not ready 
> yet, and I'm waiting for the current callout patch to settle first.


Thanks. I am going to try this patch in 10-STABLE branch.