Re: [RFC] kern/kern_timeout.c rewrite in progress

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.

--HPS