Messages in this thread | | | Date | Fri, 11 Jun 1999 13:54:25 +0100 (BST) | From | Tigran Aivazian <> | Subject | Re: generalizing khttpd |
| |
Bjorn,
Your comments on OS design are of course interesting, but perhaps before studying OS internals it is also worth to study network etiquette a bit - namely, if I wished my words to appear on linux-kernel mailing list I would have cc'd:linux-kernel myself.
As for "misconception of things being faster when in kernel mode", I am well aware of the trivial scenario you are describing but was rather mentioning it because of no need to switch between user<->kernel as opposed to running the loop itself in the kernel (otherwise almost the same can be achieved by running RT userspace code). This is why things like sys_copyfile() or sys_movedirectorytree_atomically() would be a good idea, i.e. doing things in atomic manner and without too many mode switches. In the same manner (assuming gzip is de-facto standard of compression, which it is) it would be nice to say sys_gzip("file", "file.gz") and end up with the result atomically, rather than observing a slowly increasing file.gz and then suddenly disappearing file.
Your definition of OS is valid but you seem to give a very narrow (though widely-accepted) meaning to the "application" as "userspace program". One can treat khttpd as a "kernelspace application", perhaps a revolutionary and a unique (until all other vendors start shipping their own inkernel web servers - just a guess) notion but so what?
As Lenin said "revolution is the merge of the city with a countryside" (or something along those lines) so one can make a revolutionary OS by merging applications+kernel ;)
Regards, ------ Tigran A. Aivazian | http://www.sco.com Escalations Research Group | tel: +44-(0)1923-813796 Santa Cruz Operation Ltd | http://www.aivazian.demon.co.uk
On Fri, 11 Jun 1999, Bjorn Wesen wrote:
> On Fri, 11 Jun 1999, Tigran Aivazian wrote: > > I think I have already explained to you that computers exist to perform > > the work as fast as possible and in a manner as elegant as possible, so if > > khttpd is elegant and fast it should be in the kernel. > > > > What is the point of saying "are Linux system calls so slow that we can't > > write network servers using them?"? > > As I wrote, it's a philosophy question. The more stuff that gets put into > the kernel due to speed issues, the more it turns into an embedded system > or a system like Windows. You can obviously design the system in any way > imaginable between OS and userland, there's no absolute right or wrong. > > My point is, that the main purpose of the OS is to abstract the HW and > internal OS design so that applications can run on top of it. One of Linux > main points is that it's one of the fastest networking OS'es available - > and therefore, it should be possible to write efficient networking > applications _without_ bypassing the OS. > > This is not bashing khttpd, this is bashing the Linux architecture itself > if anything, but in a constructive manner (I hope). > > > Remember that the reason why, e.g. ktar or kgzip do not exist is not > > because it wouldn't be a good idea but because nobody runs tar/gzip often > > enough (i.e. not 3000 times per second) to justify a major effort of > > writing an inkernel version. > > Again, that is a philosophy question. Stuff like the filesystem is not > primarily in the kernel because it's used a lot, it's there because it > can't be in userland due to the security needed. The same with drivers - > it's safer to keep them in the kernel than having setuid user programs > accessing the HW (compare with the problems with XFree86). > > It seems like there is a misconception that code runs faster just because > it's in kernel mode. Why would gzip be faster if it was in the kernel? It > wouldn't, and it would slow the entire system because the Linux kernel is > not pre-empted, so while in your fat gzip loop that cpu won't switch. > You'd have to keep polling need_resched equivalents etc. And if this > wasn't the case, it'd still not be faster than user-mode. > > For the same reason it would be stupid to put audio codecs and processing > algorithms inside the kernel. > > In short, the OS development strives to minimize any user-mode latencies, > and putting everything that's used a lot into the kernel only means we > risk taking a step back into an era filled with incompatibilities, upgrade > nightmares and architectural locking since too much depend on the internal > architecture of the kernel. > > > The situation with web serving is rather > > different - a lot of people want it to be faster and faster so one > > solution is to put it in the kernel. Also, it may be worth it even for the > > sake of winning those stinking benchmarks that people of little > > understanding use to compare Linux with the "other" OSes. > > One solution, maybe. Not necessarily _the_ solution. > > /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/
| |