Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 May 1999 13:34:05 -0700 (PDT)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Cc:        Pierre Beyssac <beyssac@enst.fr>, freebsd-current@FreeBSD.ORG
Subject:   Re: mbuf starvation
Message-ID:  <199905122034.NAA88116@apollo.backplane.com>
References:  <19990512172544.A440@enst.fr> <199905121656.MAA00970@khavrinen.lcs.mit.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
: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 
					<dillon@backplane.com>

:--
: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
:



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?199905122034.NAA88116>