From owner-freebsd-hackers Thu Nov 18 7:16: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gw0.boostworks.com (gw0.boostworks.com [194.167.81.213]) by hub.freebsd.org (Postfix) with ESMTP id 7CC86153FE for ; Thu, 18 Nov 1999 07:15:42 -0800 (PST) (envelope-from root@synx.com) Received: from synx.com (root@rn.synx.com [192.1.1.241]) by gw0.boostworks.com (8.9.1/8.9.1) with ESMTP id QAA38881; Thu, 18 Nov 1999 16:13:28 +0100 (CET) Message-Id: <199911181513.QAA38881@gw0.boostworks.com> Date: Thu, 18 Nov 1999 16:13:25 +0100 (CET) From: Remy Nonnenmacher Reply-To: remy@synx.com Subject: Re: mbuf wait code (revisited) -- review? To: bmilekic@dsuper.net Cc: julian@whistle.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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