Date: Thu, 18 Nov 1999 08:22:28 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: David Greenman <dg@root.com> Cc: remy@synx.com, bmilekic@dsuper.net, julian@whistle.com, freebsd-hackers@FreeBSD.ORG Subject: Re: mbuf wait code (revisited) -- review? Message-ID: <199911181622.IAA85547@apollo.backplane.com> References: <199911181535.HAA15679@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
<dillon@backplane.com>
:
:>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911181622.IAA85547>