svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

[Hans Petter Selasky]

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