Date: Thu, 03 Oct 2024 01:56:11 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 281560] gve (4) uma deadlock during high tcp throughput Message-ID: <bug-281560-7501-8RTN2SC5fi@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-281560-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-281560-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D281560 --- Comment #19 from Konstantin Belousov <kib@FreeBSD.org> --- (In reply to shailend from comment #18) Locks (except spinlocks) do not have any magic properties WRT disabling scheduling. So it is absolutely fine for a thread owning a lock to be put off CPU if there is another thread with higher priority. OTOH, for locks like mutexes and rwlocks (that use turnstiles) the system propagates priorities from lock contenders to lock owners to avoid priority inversion. Which raises the question, what is the priority of that running tx thread vs the priority of the lock owner? Could it be that the tx thread was assigned too high priority, causing this live-lock? --=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?bug-281560-7501-8RTN2SC5fi>