Messages in this thread | | | Date | Fri, 11 Jun 1999 11:22:21 +0200 (MET DST) | From | Bjorn Wesen <> | Subject | Re: generalizing khttpd |
| |
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/
| |