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
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.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"