Date: Thu, 18 Nov 1999 16:13:25 +0100 (CET) From: Remy Nonnenmacher <remy@synx.com> To: bmilekic@dsuper.net Cc: julian@whistle.com, freebsd-hackers@FreeBSD.ORG Subject: Re: mbuf wait code (revisited) -- review? Message-ID: <199911181513.QAA38881@gw0.boostworks.com> In-Reply-To: <Pine.OSF.4.05.9911180943360.28163-100000@oracle.dsuper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. RN. IaM 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?199911181513.QAA38881>