Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 6 Sep 2002 15:00:42 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 6 Sep 2002 15:00:41 -0400 Received: from pizda.ninka.net ([216.101.162.242]:21895 "EHLO pizda.ninka.net") by vger.kernel.org with ESMTP id ; Fri, 6 Sep 2002 15:00:41 -0400 Date: Fri, 06 Sep 2002 11:58:04 -0700 (PDT) Message-Id: <20020906.115804.109349169.davem@redhat.com> To: gh@us.ibm.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 Subject: Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000 From: "David S. Miller" In-Reply-To: References: <20020906.113448.07697441.davem@redhat.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1005 Lines: 21 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. - 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/