Date: Tue, 27 May 1997 23:32:39 -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.970527230202.11962C-100000@rodan.syr.edu> In-Reply-To: <Pine.LNX.3.91.970527180624.1463I-100000@zen.cypher.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 27 May 1997, Ben Black wrote: > > > > > > how do you spell kludge? > > > > Why does this qualify as a kludge (and a better question might be "how do > > you pronounce kludge?" :). > > > > it is a kludge because it is in there for EXACTLY one purpose. you > couldn't use the facilities for any but transferring a file from one host > to another. it is only there to get around a general problem for a > specific application. that's a kludge. Gee, one of the most common applications for web servers, news servers, ftp servers. Probably a general problem that represents 60-80% of today's internet traffic. > > 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? > > and if not, is that because the kernel needs to be reworked rather than > hacked up to solve a single problem. If I understood the site you referenced in your other post, your alternative is putting an IO interpreter into the kernel? Heck, why not just put java in kernel space and write all the I/O in java. Sounds like a smaller, faster kernel to me. Next you'll want interpreters to handle complex permissions manipulation, and page remapping, etc. > > 2. can it be implemented in userland and if so, is it likely to be highly > > duplicated code? > > and if it can be implemented well at user level and is duplicated code, > why is that code in the kernel at all? > > > 3. what is the expense to the kernel of doing this? > > > > > > The answer to #1 is yes, much more efficiently. > > because there is no *general* facility for doing high-speed, low-latency > networking. this does not argue for the nastiness you describe in NT. I prefer simple, reliable system calls to interpreters in the kernel any day. I also prefer solutions that are likely to exist soon rather than ones which may not exist for months or years. > > The answer to #2 is yes, it can, but it is very likely to be duplicated > > see above. > > > The answer to #3 is a maybe 1k of code (at most) and no mods to critical > > performance sections in the kernel. > > > > 1k of application specific code. sounds like a waste. Not if that code can provide a non-trivial performance boost, *and* reduce application code sizes by roughly the same amount multiplied by the number of processes running using such facilities. > > #2 is really a test question for a library rather than the kernel, but, > > where applicable, it should also be applied to kernel calls. > > > > 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). > > > > so use 800 threads with a single fd each. And I do this with FreeBSD using what, the thread package that implements it as a select() in the background? So, in addition to reimplementing the I/O subsystem, you'd like me to add multithreading, too? > > > > 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. > > > > and you have presented no evidence that it needs to be in the kernel. i > have suggested fbufs and various eros techniques while you have just > listed why *something* is needed. > > it *can* be done cleanly and quickly assuming proper kernel support. > adding an application specific system call to the kernel is just a bad idea. So far the kernel possibilities you have presented are not implemented for FreeBSD and probably won't be any time in the near future. Some of them have problems that don't have clear win/win outcomes (like I/O interpreters in the kernel). I can certainly imagine that some or all of these may provide more optimal I/O services. I don't think that you've demonstrated that the net gain of providing all this generalized service will result in greater overall efficiency than implementing my single, clean optimization, since I'd argue that the majority use will be the simple case, and you'll have made that case less efficient than it might be otherwise. I think transmitfile has a win/win outcome--it is small and simple to implement in the kernel, and provides code reduction and a non-trivial performance boost on the userland side. -Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SOL.3.95.970527230202.11962C-100000>