Hi Slawa, On 9/21/16 10:31 AM, Slawa Olhovchenkov wrote: > On Wed, Sep 21, 2016 at 09:11:24AM +0200, Julien Charbon wrote: >> On 9/20/16 10:26 PM, Slawa Olhovchenkov wrote: >>> On Tue, Sep 20, 2016 at 10:00:25PM +0200, Julien Charbon wrote: >>>> On 9/19/16 10:43 PM, Slawa Olhovchenkov wrote: >>>>> On Mon, Sep 19, 2016 at 10:32:13PM +0200, Julien Charbon wrote: >>>>>> >>>>>>> @ CPU_CLK_UNHALTED_CORE [4653445 samples] >>>>>>> >>>>>>> 51.86% [2413083] lock_delay @ /boot/kernel.VSTREAM/kernel >>>>>>> 100.0% [2413083] __rw_wlock_hard >>>>>>> 100.0% [2413083] tcp_tw_2msl_scan >>>>>>> 99.99% [2412958] pfslowtimo >>>>>>> 100.0% [2412958] softclock_call_cc >>>>>>> 100.0% [2412958] softclock >>>>>>> 100.0% [2412958] intr_event_execute_handlers >>>>>>> 100.0% [2412958] ithread_loop >>>>>>> 100.0% [2412958] fork_exit >>>>>>> 00.01% [125] tcp_twstart >>>>>>> 100.0% [125] tcp_do_segment >>>>>>> 100.0% [125] tcp_input >>>>>>> 100.0% [125] ip_input >>>>>>> 100.0% [125] swi_net >>>>>>> 100.0% [125] intr_event_execute_handlers >>>>>>> 100.0% [125] ithread_loop >>>>>>> 100.0% [125] fork_exit >>>>>> >>>>>> The only write lock tcp_tw_2msl_scan() tries to get is a >>>>>> INP_WLOCK(inp). Thus here, tcp_tw_2msl_scan() seems to be stuck >>>>>> spinning on INP_WLOCK (or pfslowtimo() is going crazy and calls >>>>>> tcp_tw_2msl_scan() at high rate but this will be quite unexpected). >>>>>> >>>>>> Thus my hypothesis is that something is holding the INP_WLOCK and not >>>>>> releasing it, and tcp_tw_2msl_scan() is spinning on it. >>>>>> >>>>>> If you can, could you compile the kernel with below options: >>>>>> >>>>>> options DDB # Support DDB. >>>>>> options DEADLKRES # Enable the deadlock resolver >>>>>> options INVARIANTS # Enable calls of extra sanity >>>>>> checking >>>>>> options INVARIANT_SUPPORT # Extra sanity checks of internal >>>>>> structures, required by INVARIANTS >>>>>> options WITNESS # Enable checks to detect >>>>>> deadlocks and cycles >>>>>> options WITNESS_SKIPSPIN # Don't run witness on spinlocks >>>>>> for speed >>>>> >>>>> Currently this host run with 100% CPU load (on all cores), i.e. >>>>> enabling WITNESS will be significant drop performance. >>>>> Can I use only some subset of options? >>>>> >>>>> Also, I can some troubles to DDB enter in this case. >>>>> May be kgdb will be success (not tryed yet)? >>>> >>>> If these kernel options will certainly slow down your kernel, they also >>>> might found the root cause of your issue before reaching the point where >>>> you have 100% cpu load on all cores (thanks to INVARIANTS). I would >>>> suggest: >>> >>> Hmmm, may be I am not clarified. >>> This host run at peak hours with 100% CPU load as normal operation, >>> this is for servering 2x10G, this is CPU load not result of lock >>> issuse, this is not us case. And this is because I am fear to enable >>> WITNESS -- I am fear drop performance. >>> >>> This lock issuse happen irregulary and may be caused by other issuse >>> (nginx crashed). In this case about 1/3 cores have 100% cpu load, >>> perhaps by this lock -- I am can trace only from one core and need >>> more then hour for this (may be on other cores different trace, I >>> can't guaranted anything). >> >> I see, especially if you are running in production WITNESS might indeed >> be not practical for you. In this case, I would suggest before doing >> WITNESS and still get more information to: >> >> #0: Do a lock profiling: >> >> https://www.freebsd.org/cgi/man.cgi?query=LOCK_PROFILING >> >> options LOCK_PROFILING >> >> Example of usage: >> >> # Run >> $ sudo sysctl debug.lock.prof.enable=1 >> $ sleep 10 >> $ sudo sysctl debug.lock.prof.enable=0 >> >> # Get results >> $ sysctl debug.lock.prof.stats | head -2; sysctl debug.lock.prof.stats | >> sort -n -k 4 -r > > OK, but in case of leak lock (why inp lock too long for > tcp_tw_2msl_scan?) I can't see cause of this lock running this > commands after stuck happen? > >>> What purpose to not skip locked tcptw in this loop? >> >> If I understand your question correctly: According to your pmcstat >> result, tcp_tw_2msl_scan() currently struggles with a write lock >> (__rw_wlock_hard) and the only write lock used tcp_tw_2msl_scan() is >> INP_WLOCK. No sign of contention on TW_RLOCK(V_tw_lock) currently. > > As I see in code, tcp_tw_2msl_scan got first node from V_twq_2msl and > need got RW lock on inp w/o alternates. Can tcp_tw_2msl_scan skip current node > and go to next node in V_twq_2msl list if current node locked by some > reasson?
Interesting question indeed: It is not optimal that all simultaneous calls to tcp_tw_2msl_scan() compete for the same oldest tcptw. The next tcptws in the list are certainly old enough also. Let me see if I can make a simple change that makes kernel threads calling tcp_tw_2msl_scan() at same time to work on a different old enough tcptws. So far, I found only solutions quite complex to implement. -- Julien
signature.asc
Description: OpenPGP digital signature
