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

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