lkml.org 
[lkml]   [2002]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Early SPECWeb99 results on 2.5.33 with TSO on e1000
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:28    [W:0.128 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site