Date: Thu, 20 Aug 1998 00:34:06 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: oppermann@pipeline.ch (Andre Oppermann) Cc: hackers@FreeBSD.ORG Subject: Re: combined accept&read Message-ID: <199808200034.RAA29701@usr05.primenet.com> In-Reply-To: <35DB0422.B6447353@pipeline.ch> from "Andre Oppermann" at Aug 19, 98 06:58:10 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I was chatting a little bit with the Zeus developers to ask them how > to make FreeBSD the best/fastest platform for them. > > "accept&read combined call is something else we're toying with. Very > often we get a poll/select broken because there's data coming in on a > socket, and most of the time there's already data in the socket > buffers. Being able to do the accept() and read() in a single call > should be beneifital." > > They also wish to have a few thousand open fd's without slowing > down stuff like get_first_free_fd(). > > Something like this would also help our Apache friends (and maybe > DG-FTP on ftp.cdrom.com) I think ;-). > > Opinions? The combination of open+stat, getdents+stat, and others, are all in the same category: system calls implemented as appologists for existing usage models. Because the FAT/VFAT/VFAT32 inode *is* the directory entry, it is very inexpensive to do both simultaneously (doing one, by definition, results in the other). Because of this, SMB has developed a need to do this. When someone does an SMB "open" call, you *must* stat the file to return the open information returned by that call to make the SMB client happy by giving it the information returned by the WIN32 call, which may or may not be used. You can make similar arguments for globbing in the kernel (to avoid pushing useless data across the user/kernel boundary at 2uS a pop), and for directory vs. file data returned, and for prefaulting all inodes as their numbers are seen in a directory traversal, etc.. There are a lot of optimizations that fall into this category. Now what happens when you've done this? People will rely on them. Then after people rely on them, the UNIX applciations get just as bulky as the NT applications; want a file open? Better allocate a stat buffer, before you call open... etc.. The mmap option saves all but one avoidable copy; that's two more copies than Linux saves, and one less than Linux, if Linux does it right. You could save even more copies if you stored data in minimal MTU sized chunks with TCP headers attached so that you read one MTU of data, and write one MTU of data. This would let you DMA from the disk controller into ethernet card memory, and then fixup the header contents that vary (like target machine). Be sure to use hardware that does the checksumming for you... Better to do optimizations, like exporting a "system ID" and allowing proxy locking in the kernel and exposing the NFS LEASE mechanism for use by SAMBA (NFS LEASEs are "Opportunity Locks" -- BSD beats Microsoft to yet another technology, but MS renames it and grabs the headlines). Things like fd caching after close in the SMB server, for example, are worth a 15% performance inprovement in .BAT and .INI processing to a DOS/Windows client. There are a lot of wins out there, and it's silly to concentrate on the ones which, architecturally, are not very big wins for FreeBSD, even if they may be big wins for OS's with a different architecture (like Linux). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808200034.RAA29701>