From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerrit Huizenga Subject: Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000 Date: Fri, 06 Sep 2002 12:52:15 -0700 Sender: netdev-bounce@oss.sgi.com Message-ID: References: <20020906.115804.109349169.davem@redhat.com> Reply-To: Gerrit Huizenga Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Martin.Bligh@us.ibm.com, hadi@cyberus.ca, tcw@tempest.prismnet.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, niv@us.ibm.com Return-path: To: "David S. Miller" In-Reply-To: Your message of Fri, 06 Sep 2002 11:58:04 PDT. <20020906.115804.109349169.davem@redhat.com> Content-ID: <15685.1031341935.1@us.ibm.com> Errors-to: netdev-bounce@oss.sgi.com List-Id: netdev.vger.kernel.org In message <20020906.115804.109349169.davem@redhat.com>, > : "David S. Miller" writes: > From: Gerrit Huizenga > Date: Fri, 06 Sep 2002 11:57:39 -0700 > > Out of curiosity, and primarily for my own edification, what kind > of optimization does it do when everything is generated by a java/ > perl/python/homebrew script and pasted together by something which > consults a content manager. In a few of the cases that I know of, > there isn't really any static content to cache... And why is this > something that Apache couldn't/shouldn't be doing? > > The kernel exec's the CGI process from the TUX server and pipes the > output directly into a networking socket. > > Because it is cheaper to create a new fresh user thread from within > the kernel (ie. we don't have to fork() apache and thus dup it's > address space), it is faster. So if apache were using a listen()/clone()/accept()/exec() combo rather than a full listen()/fork()/exec() model it would see most of the same benefits? Some additional overhead for the user/kernel syscall path but probably pretty minor, right? Or did I miss a piece of data, like the time to call clone() as a function from in kernel is 2x or 10x more than the same syscall? gerrit