| raw e-mail | index | archive | help
And now lets see whats happening on cpu 31: ``` db> show pcpu 31 cpuid =3D 31 dynamic pcpu =3D 0xfffffe009a579d80 curthread =3D 0xfffff800a8501740: pid 0 tid 100453 critnest 0 "gve0 txq = 10 xmit" curpcb =3D 0xfffff800a8501c60 fpcurthread =3D none idlethread =3D 0xfffff80003b04000: tid 100034 "idle: cpu31" self =3D 0xffffffff8242f000 curpmap =3D 0xffffffff81b79c50 tssp =3D 0xffffffff8242f384 rsp0 =3D 0xfffffe01a4ca8000 kcr3 =3D 0xffffffffffffffff ucr3 =3D 0xffffffffffffffff scr3 =3D 0x0 gs32p =3D 0xffffffff8242f404 ldt =3D 0xffffffff8242f444 tss =3D 0xffffffff8242f434 curvnet =3D 0 spin locks held: ``` Sure enough a driver transmit thread is hogging the cpu. And to seal the lo= op, lets see what this queue's cleanup thread is doing: ``` db> show lockchain 100452 thread 100452 (pid 0, gve0 txq 10) is blocked on lock 0xfffffe00df57a3d0 (s= leep mutex) "mbuf" thread 100708 (pid 860, iperf) is on a run queue ``` In summary this is the usual loop: iperf thread (with uma zone lock) ---sched---> gve tx xmit thread ---for room---> gve tx cleanup thread -----uma zone lock----> iperf thread=20=20 There is clearly a problematic behavior in the driver transmit thread (gve_xmit_br): this taskqueue should not enqueue itself, and should rather = let the cleanup taskqueue wake it up when room is made in the ring, so I'll wor= k on that.=20=20 But I also want to confirm that it is not problematic for an iperf thread t= o be knocked off the cpu with the zone lock held: is it not a critical enough lo= ck to disallow that? (I am not very familiar with schedulers to know if this i= s a naive question). --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?>