On 01/21/15 01:49, Adrian Chadd wrote:
You should totally try say, 100,000 active TCP connections on a box.
See what happens to swi0 (clock).
TL;DR - the lock contention sucks and it takes a chunk of the core up.
The lock contention is highly not good.
That's why I'd like to see both the callout stuff in its
slightly-better-defined-and-sane state from you/and/ make it so TCP
can use it.
I'll have to double-check to see if the RSS stuff is all lined up
correctly so we can use it when we create the callouts (well, at inpcb
creation time, right), rather than when we first schedule them. Then
we can experiment with having the initial CPU be specified at callout
create time rather than expecting to be able to move it when we first
schedule it.
Or, hm, maybe have it so we don't have a CPU chosen until the first
time we schedule the timeout, and if it hasn't been scheduled before,
allow the CPU to be set? Because at that point we aren't migrating it
off f timeout_cpu - it's never been added to it in the first place.
Hi Adrian,
What you are saying is correct. If you set the initial c_cpu value when
the callout is initialized it will run on SWI#X instead of SWI#0. This
is fully allowed, so maybe a callout_init_cpu() would be appropriate, to
set the initial CPU number for callouts. With regard to the callout the
c_cpu value can be different from zero, only the it must remain
fixed/constant when there is no lock protecting updates to it!
Kip and Gleb: Does adding a callout_init_cpu() function which can be
used for existing callouts and in conjunction with CALLOUT_MPSAFE change
anything?
--HPS
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
