Re: [rfc] bind per-cpu timeout threads to each CPU

On 2/19/14, 12:04 PM, Adrian Chadd wrote:
> On 19 February 2014 11:59, Alexander Motin <mav@freebsd.org> wrote:
>
>>> So if we're moving towards supporting (among others) a pcbgroup / RSS
>>> hash style work load distribution across CPUs to minimise
>>> per-connection lock contention, we really don't want the scheduler to
>>> decide it can schedule things on other CPUs under enough pressure.
>>> That'll just make things worse.
>> True, though it is also not obvious that putting second thread on CPU run
>> queue is better then executing it right now on another core.
> Well, it depends if you're trying to optimise for "run all runnable
> tasks as quickly as possible" or "run all runnable tasks in contexts
> that minimise lock contention."
>
> The former sounds great as long as there's no real lock contention
> going on. But as you add more chances for contention (something like
> "100,000 concurrent TCP flows") then you may end up having your TCP
> timer firing stuff interfere with more TXing or RXing on the same
> connection.
>
> Chasing this stuff down is a pain, because it only really shows up
> when you're doing lots of concurrency.
>
> I'm happy to make this a boot-time option and leave it off for the
> time being. How's that?

options THROUGHPUT

Yes, looks like a latency vs throughput issue.  One giant switch might 
be a starting point so that it doesn't become death of 1000 switches to 
get throughput or latency sensitive work done.

>
>
>
> -a
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
>

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"