Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000

In message [off-list ref], > : "David S. Miller" 
writes:

   From: Gerrit Huizenga [off-list ref]
   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

   From: Gerrit Huizenga [off-list ref]
   Date: Fri, 06 Sep 2002 12:52:15 -0700
   
   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?

Apache would need to do some more, such as do something about
cpu affinity and do the non-blocking VFS tricks Tux does too.

To be honest, I'm not going to sit here all day long and explain how
Tux works.  I'm not even too knowledgable about the precise details of
it's implementation.  Besides, the code is freely available and not
too complex, so you can go have a look for yourself :-)