Date: Tue, 27 May 1997 18:00:36 -0400 (EDT) From: Christopher Sedore <cmsedore@mailbox.syr.edu> To: Ben Black <black@zen.cypher.net> Cc: Ruslan Shevchenko <rssh@cki.ipri.kiev.ua>, FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff Message-ID: <Pine.SOL.3.95.970527165604.11761B-100000@rodan.syr.edu> In-Reply-To: <Pine.LNX.3.91.970527162845.1463E-100000@zen.cypher.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SOL.3.95.970527165604.11761B-100000>