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?


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).


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.

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to