From owner-freebsd-current Wed May 12 13:34:19 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id C503F14C21 for ; Wed, 12 May 1999 13:34:17 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA88116; Wed, 12 May 1999 13:34:05 -0700 (PDT) (envelope-from dillon) Date: Wed, 12 May 1999 13:34:05 -0700 (PDT) From: Matthew Dillon Message-Id: <199905122034.NAA88116@apollo.backplane.com> To: Garrett Wollman Cc: Pierre Beyssac , freebsd-current@FreeBSD.ORG Subject: Re: mbuf starvation References: <19990512172544.A440@enst.fr> <199905121656.MAA00970@khavrinen.lcs.mit.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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 :-- :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