Date: Tue, 27 May 1997 23:57:36 -0400 (EDT) From: Ben Black <black@zen.cypher.net> To: Christopher Sedore <cmsedore@mailbox.syr.edu> Cc: Ruslan Shevchenko <rssh@cki.ipri.kiev.ua>, FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff Message-ID: <Pine.LNX.3.91.970527234336.10761C-100000@zen.cypher.net> In-Reply-To: <Pine.SOL.3.95.970527230202.11962C-100000@rodan.syr.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > 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. > and since 99% of the world's computers are connected to the internet as web, news, or ftp servers... > > > 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. > 1) stick to what i actually said, and stop putting ridiculous words in my mouth. 2) it is not a complete lagnuage interpreter, it is simply a compact system for dynamically adding system call to the kernel by aggregating existing system calls. contrast this with your approach which requires adding special purpose code to the kernel for EVERY "common" sequence of syscalls. > > 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. > so you prefer solutions that involve no thoughtful design and testing. this explains why you are pushing an obviously flawed solution implemented by M$. > > 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. > 1K reduction in the size of the 100 or so web server running on a pretty busy system at once...you saved a whole 100k! and all it cost was adding yet more uneeded bloat to the kernel. the solution i offered has the potential to boost performance for applications which aren't even around yet. your solution becomes bloat as soon as application needs change. > > > #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? > it was an either or. and neither matters since i doubt you will actaully be implementing any of this. > > > > 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). > no, they are not yet implemented, but the source is there, the core team is eager to make the system better...what's stopping you? a small syscall aggregator in the kernel would take up perhaps 5-10k and provide limitless applications. your solution solves a single current problem and totally ignores the rest of the world. > 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. > of course you'd argue the majority would use the simple case: you are only considering a SINGLE application. > 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. > the code reduction is a non-issue and just because something *can* be implemented in the kernel doesn't mean it *should* be implemented in the kernel. if something is only supposed to help out a small fraction of applications it belongs in userland. show me how TransmitFile() helps emacs or gcc or xwin. i'd bet more people use those applications than run their own web/ftp/news servers on their machine. b3n
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.91.970527234336.10761C-100000>