: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
Doing something like this is exactly what was intented for asleep().
The code is not entirely complete, though. Basically the idea is to
use asleep() in situations where the system might block but does not
normally block in order to avoid both deadlocks and unnecessary code
serialization ( due to holding a lock through a blocking situation ).
This becomes critically important in SMP models where most of the locks
you hold are spinlocks rather then scheduler locks.
asleep() allows a subroutine deep in the call stack to specify an
asynchronous blocking condition and then return a temporary failure
up through the ranks. At the top level, the scheduler sees and acts
upon the asynchronous blocking condition. Higher level routines do not
need to understand what condition is being blocked on, only that there
is some condition being blocked on. With the current model, higher
level routines have to assume that lower level routines may block which
complicates matters greatly.
-Matt
Matthew Dillon
<dil...@backplane.com>
:--
:Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same
:woll...@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 majord...@freebsd.org
:with "unsubscribe freebsd-current" in the body of the message
:
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
