Date: Wed, 12 May 1999 12:56:39 -0400 (EDT) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> To: Pierre Beyssac <beyssac@enst.fr> Cc: freebsd-current@FreeBSD.ORG Subject: mbuf starvation Message-ID: <199905121656.MAA00970@khavrinen.lcs.mit.edu> In-Reply-To: <19990512172544.A440@enst.fr> References: <19990512172544.A440@enst.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Wed, 12 May 1999 17:25:44 +0200, Pierre Beyssac <beyssac@enst.fr> said: > Another big problem is that there's a check in m_retry and friends > that panics when falling short of mbufs! I really believe this does > more harm than good, because it prevents correct calling code > (checking for NULL mbuf pointers) from exiting gracefully with > ENOBUFS... I think we need to think a bit more about the right semantics before making such a change. M_WAIT is supposed to mean `I am in process context and don't mind sleeping in order to get an mbuf, but there is too much locking going on inside the network stack to be able to safely sleep without serious risk of deadlock. This is the sort of application which would be ideal for Matt's `asleep' interface. Then, the code could back its way out of any locks and spls, safely wait for sufficient mbufs to be freed, and then retry. Even then, it's still possible to deadlock if one process hogs the entire mbuf pool. It may be necessary to incrementally penalize processes which do so. FWIW, the 4.3 code sleeps in a loop. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905121656.MAA00970>