From owner-freebsd-hackers Tue May 27 15:00:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA06205 for hackers-outgoing; Tue, 27 May 1997 15:00:49 -0700 (PDT) Received: from mailer.syr.edu (mailer.syr.edu [128.230.20.20]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA06197 for ; Tue, 27 May 1997 15:00:46 -0700 (PDT) Received: from rodan.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1a) with SMTP id <0.E225DE60@mailer.syr.edu>; Tue, 27 May 1997 18:00:38 -0400 Received: from localhost (cmsedore@localhost) by rodan.syr.edu (8.8.5/8.8.5) with SMTP id SAA22732; Tue, 27 May 1997 18:00:37 -0400 (EDT) X-Authentication-Warning: rodan.syr.edu: cmsedore owned process doing -bs Date: Tue, 27 May 1997 18:00:36 -0400 (EDT) From: Christopher Sedore X-Sender: cmsedore@rodan.syr.edu Reply-To: Christopher Sedore To: Ben Black cc: Ruslan Shevchenko , FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 27 May 1997, Ben Black wrote: > > > > Well, you might better arrange to be amazed :) It is an NT system call. > > It's exact purpose is to avoid a read(file,buf)/write(sock,buf) loop with > > the associated user/system switch for each call. Async doesn't buy you > > anything here except the ability to do it in the background. > > > > how do you spell kludge? Why does this qualify as a kludge (and a better question might be "how do you pronounce kludge?" :). It seems to me that a good test set for what facilities should be in the kernel might include: 1. can the kernel do it significantly more efficiently that the user? 2. can it be implemented in userland and if so, is it likely to be highly duplicated code? 3. what is the expense to the kernel of doing this? The answer to #1 is yes, much more efficiently. The answer to #2 is yes, it can, but it is very likely to be duplicated The answer to #3 is a maybe 1k of code (at most) and no mods to critical performance sections in the kernel. #2 is really a test question for a library rather than the kernel, but, where applicable, it should also be applied to kernel calls. > > > btw, NT is probably the WORST place to look for inspiration. just look > > > at their TCP sequence generation algorithm. > > > > I figure that I'll borrow good ideas from where ever they come...Nobody > > does everything "right" by universal or any given individual's standards. > > > > no, but some places have more wrong than others. > > > I'd just like to see FreeBSD add some enhancements to make it easier/more > > efficient for high load network applications (since I'm now breaking NT's > > something like fbufs would be a general purpose and cleaner solution to > the issue of high-speed IO. the NT syscall you describe is nothing but a > giant hairy hack. > > > IP stack under load). Threads (true threads, mind you) would be nice, > > breaking the NT tcp stack is no major accomplishment. Maybe not, but I don't think I could even get my code to run under FBSD without some non-trivial rearrangement because of facilities that don't exist or are costly to use (I'm not happy about the idea of checking 800 connections with an FD_ISSET() loop). > > but kernel based async IO and a few other goodies would make a big > > difference. > > > > again, the kernel need not provide these facilities as long as they > appear at user level (yes, this can be done, see www.cis.upenn.edu/~eros) > > i would rather the kernel got *smaller* and *faster* than more loaded > down with features. how about a giant rearchitecting for FreeBSD 4.0? ;) You can shrink the kernel continuously, down to something like: kernel: jmp kernel and it will be very fast, but not terribly useful. :) This certainly maximizes both your criteria for kernel characteristics (and it also would probably meet very stringent reliability standards :). I happen to have more criteria than small and fast. Functions that can be executed without penalty in userland should be, those that are highly duplicated and pay an userland penalty deserve consideration for kernel inclusion, IMHO. -Chris