From owner-freebsd-hackers Thu Apr 3 12:34:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA14457 for hackers-outgoing; Thu, 3 Apr 1997 12:34:57 -0800 (PST) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA14452 for ; Thu, 3 Apr 1997 12:34:55 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.5/8.7.3) with UUCP id NAA12801; Thu, 3 Apr 1997 13:34:48 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id NAA02837; Thu, 3 Apr 1997 13:34:30 -0700 (MST) Date: Thu, 3 Apr 1997 13:34:29 -0700 (MST) From: Marc Slemko To: David Greenman cc: FreeBSD-hackers Subject: Re: apache like preforking apps and high loads In-Reply-To: <199704031527.HAA03657@root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 3 Apr 1997, David Greenman wrote: > >When looking at Apacha like applications, one often sees extermely high > >load averages. Apache preforks a number of processes that all block > >on accept(). When a request comes in, all process are woken up and the > >scheduler chooses one of the now runnable processes taht will succeed in > >the accept(). The other go back to sleep. > > Not any more. I changed this a few days ago. Now only one process is > woken up. Looking at these changes and the other code around them, it appears to me like the net effect is that processes are added to the tail of the queue when they block on accept() and removed from (near) the head with wakeup_one. Am I reading this right, or am I getting my queue ends mixed up somewhere? For code that does similar things to what Apache does, it would be far better to treat it as a stack and have wakeup_one() remove from the tail since you want the same processes to serve as many requests as possible. In the grand scheme of things it may be a bad idea to have wakeup_one() behave this way, but it looks like it would be useful in this case.