Re: generalizing khttpd

Bjorn Wesen (bjorn@sparta.lu.se)
Fri, 11 Jun 1999 11:22:21 +0200 (MET DST)


On 11 Jun 1999, H. Peter Anvin wrote:
> > I was under the impression that khttpd had other reasons for going
> > kernel mode such as faster ability to get timestamps and what not on
> > the file itself.
>
> Actually, the main reason would be to avoid the context switch to user
> mode and back after the packet arrives; in addition, on the more
> exotic level it would be possible for it to do odd thinks like keep
> things cached in ready-made skbuffs.

To say this in other words - what you're saying is that the system calls
on Linux are so slow that you can't use them to write network servers ?
And that the "correct" solution to that is to give up and put everything
inside the kernel ?

This is a philosophy question of course, but, this surely must be a "road
to hell" because just as with direct device<->device HW serving, you'll
end up doing a lot of redundant code probably, and a lot of internal
kernel implementation dependencies.

Also this resembles our fine discussion on zero-copy fileserving.

If the syscall latency really is that bad for performance (given that you
use sendfile() and friends), wouldn't a more modest approach be to
architecture some kind of "low latency service" layer, where these servers
can live. Kind of like kernel modules, but with a tighter API towards the
kernel. Something that both knfsd and khttpd could run on top of - like a
"generalized kttpd" but in another way than the original poster suggested.

How is this solved in other OS'es ? IS really a httpd on linux that bad ?

/Bjorn

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/