On 01/20/15 09:22, Adrian Chadd wrote: > Yeah, it looks like you set c_cpu to timeout_cpu in > _callout_init_locked(), but then you only handle the case of the CPU > being changed in certain circumstances. You aren't handling the CPU > being initialised when the callout is first added. > > And, callout_restart_async() calls callout_lock(), which calls > CC_LOCK() on the callout CPU, which initially is zero. Then, it never > seems to be 'moved' into the correct CPU, even though it's being > called with a CPU id. > > So, if I am reading this all correctly, you aren't really handling > multi CPU callwheels at all. ;) > > In my instance, I'm seeing quite a lot of lock contention between the > userland threads, the network RX threads and the clock thread, all > contending on a single callout wheel being used for TCP timers. One of > the early goals for fixing up the RSS stuff in -HEAD was to make > per-CPU (Well, per-RSS-bucket really) TCP timers not contend with the > NIC RX processing path, and now it does. :(
To clarify, you're seeing this with net.inet.tcp.per_cpu_timers=1? Cheers, Lawrence _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"