lkml.org 
[lkml]   [1999]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: generalizing khttpd
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/

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