[lkml]   [1999]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: generalizing khttpd
On Fri, 11 Jun 1999, Zach Brown wrote:

> > Personally I find that efforts to make serving static pages by HTTP (and
> > only static pages by http and maybe ftp) from userspace are so
> > ridiculously overdone (threads aio, signals, sendfile), and they hurt
> > non-static-files server perrformance and functionality so much (by forcing
> huh? Simply because a nice static/dynamic mix server hasn't been written
> yet does not mean its impossible or guaranteed to be ugly. Having a
> server that has a core event loop for static work which punts to heavier
> weight models for dynamic/modules/whatever is the way to go. And (big
> shock) this is the way apache is headed.

Not really. I am aware of Apache design on both Unix and Windows, and
the way it handles connections and requests can not be separated with the
way, modules are written. Apache modules API is, to say the least,
heavyweight-processing-unfriendly, and can become only more so with
introduction of threads everywhere.

> > unsuitable processing model on programmers that write modules for those
> > servers), moving this into kernel can be the lesser evil if not a
> > blessing.
> I thought people were rabidly against putting any code in the kernel. I
> must not be up on my /. to understand why we're all of a sudden in a mood
> to toss the kitchen sink into the kernel.
> the current bottleneck in serving high end static http is certainly not
> the syscall switch from user to kernel,

No, it's telling _from_ kernel to userspace that request arrived, or
that it's finally sent. And context switch between multiple processes
doing the same in userspace. All designs that I have seen were supposed to
somehow decrease the sime spent on those three operations.

> there is a lot more work that
> needs to be done. (and doing that work will speed up lots of other apps
> that use that userland api we have. Neat.)

What applications improve their performance after "thundering herd" on
accept/select problem's solution? Introduction of AIO? sendfile()?
zero-copy TCP sending? Looks for me that an awful lot of kernel
"improvements", done or requested, basically serve only to the needs
of certain kind of applications (HTTP and possibly FTP servers -- even
for SMTP and NNTP the possible improvements aren't noticeable because of
heavy processing involved).

> A userland server can serve static pages in 3 or 4 syscalls.

It's not the syscall overhead, it's the delay between when kernel knows
that something arrives or sent and userland process has a chance to react.
And the possibility to do some meaningful work in other processes while
not being interrupted by otherwise meaningless context switches.

> If you're
> telling me the overhead of doing that is more than copying the data around
> preparing skbs and the contention imposed by the bottom halves then I'll
> happily ask you to pass that pipe this-a-way, I'm obviously missing out.

Userland HTTP servers DEFINITELY don't operate at speed, limited by the
time, spent actually doing TCP. And if, like you are implying, they will
at some time, we will have to have a mechanism, capable of handling
scheduling and data handling between kernel and userspace in a manner that
can be easier done in kernel -- with the difference that no matter how
nice HTTP server developers will try to isolate modules code from
internally used I/O model, either I/O model will bleed into modules, or
modules will have severe restrictions imposed on what and when they are
allowed to do at what time.


Excellent.. now give users the option to cut your hair you hippie!
-- Anonymous Coward

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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