From owner-freebsd-hackers Thu Nov 18 8:22:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id BDBDE15460 for ; Thu, 18 Nov 1999 08:22:32 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id IAA85547; Thu, 18 Nov 1999 08:22:28 -0800 (PST) (envelope-from dillon) Date: Thu, 18 Nov 1999 08:22:28 -0800 (PST) From: Matthew Dillon Message-Id: <199911181622.IAA85547@apollo.backplane.com> To: David Greenman Cc: remy@synx.com, bmilekic@dsuper.net, julian@whistle.com, freebsd-hackers@FreeBSD.ORG Subject: Re: mbuf wait code (revisited) -- review? References: <199911181535.HAA15679@implode.root.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG wakeup_one is really a very dangerous routine to use if you aren't careful. If the one process that is woken up does not do the correct thing (call wakeup_one again if it cannot immediately get the resource it was waiting on) you can lockup the system. I would not recommend using wakeup_one in anything but an integrated manner. That is, for example, if you were to encapsulate the mbuf wait-for-free and mbuf freeing code into their own routines you could then safely implement use of wakeup_one within those routines. But if you try to implement wakeup_one in all the myrid places where the mbuf code might interact in this manner, you create serious instability in the codebase. -Matt Matthew Dillon : :>On 18 Nov, Bosko Milekic wrote: :>> :>> Although I've presently received little feedback on this... :>> :>> I found a potential problem with the patch, so I am taking the following :>> approach to bypass it. I have a feeling that there's another way, though :>> (perhaps better, conceptually). :>> :>> Consider a case where there are 40 instances of tsleep all waiting for an mbuf :>> to be freed. Consider a single mbuf beeing freed, this would awake _all_ the :>> sleepers, the first one "queued" would succeed in the [retried] MGET whereas the :>> other 39 will fail and return NULL (not necessarily having waited the designated :>> mbuf_wait time). :>> :>> I am replacing the wakeup() in the wakeup procedure with a wakeup_one and adding :>>...... :> :>Another place where a wakeup_one would be of great interest is the :>point where multiple processes are select()ing on a listen socket. Every :>incoming connection wakes every process to have them returning to user :>mode, have one succeeding in accept() and N-1 failling and returning to :>select(). It have been identified as a key improvement for, eg Apache, :>but, AFAIK, there where no proposal to provide a solving feature :>(sysctl-ized) in FBSD (Some work have been done in Linux, since a :>well-known comparative benchmark offense). Would be even more usefull :>in SMP context. : : FreeBSD has used wakeup_one() for this purpose since I wrote wakeup_one(). :In fact, it was the main reason I wrote it. Shortly after doing this the Apache :Group changed to using file locking to coordinate access to the socket and :we ended up back at square one in terms of the thundering herd. Someone needs :to modify the file locking to use wakeup_one(), but that is not as trivial :as it might first seem (think shared/exclusive locks and priority inversion). : :-DG : :David Greenman :Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org :Creator of high-performance Internet servers - http://www.terasolutions.com :Pave the road of life with opportunities. : : :To Unsubscribe: send mail to majordomo@FreeBSD.org :with "unsubscribe freebsd-hackers" in the body of the message : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message