Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S319358AbSIFTsi>; Fri, 6 Sep 2002 15:48:38 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S319362AbSIFTsi>; Fri, 6 Sep 2002 15:48:38 -0400
Received: from e1.ny.us.ibm.com ([32.97.182.101]:24262 "EHLO e1.ny.us.ibm.com")
	by vger.kernel.org with ESMTP id <S319358AbSIFTsh>;
	Fri, 6 Sep 2002 15:48:37 -0400
To: "David S. Miller" <davem@redhat.com>
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
Reply-To: Gerrit Huizenga <gh@us.ibm.com>
From: Gerrit Huizenga <gh@us.ibm.com>
Subject: Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000 
In-reply-to: Your message of Fri, 06 Sep 2002 11:58:04 PDT.
             <20020906.115804.109349169.davem@redhat.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <15685.1031341935.1@us.ibm.com>
Date: Fri, 06 Sep 2002 12:52:15 -0700
Message-Id: <E17nP9R-000453-00@w-gerrit2>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1510
Lines: 33

In message <20020906.115804.109349169.davem@redhat.com>, > : "David S. Miller" 
writes:
>    From: Gerrit Huizenga <gh@us.ibm.com>
>    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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/