On 19.02.2014 21:51, Adrian Chadd wrote:
On 19 February 2014 11:40, Alexander Motin <m...@freebsd.org> wrote:
Clock interrupt threads, same as other ones are only softly bound to
specific CPUs by scheduler preferring to run them on CPUs where they are
scheduled. So far that was enough to balance load, but allowed threads to
migrate, if needed. Is it too flexible for some use case?
I saw it migrate under enough CPU load / pressure, right smack bang in
the middle of doing TCP processing.
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.
--
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
