Date: Thu, 15 Jul 1999 18:42:31 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: davids@webmaster.com (David Schwartz) Cc: tlambert@primenet.com, Doug@gorean.org, scrappy@hub.org, beyssac@enst.fr, chat@FreeBSD.ORG Subject: Re: Known MMAP() race conditions ... ? Message-ID: <199907151842.LAA29095@usr07.primenet.com> In-Reply-To: <000001bece6b$bcf66740$021d85d1@youwant.to> from "David Schwartz" at Jul 14, 99 07:42:53 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I'll give you a contrived example, since I'm not at liberty to go into > details on the specifics of real examples. Suppose I might potentially have > to do 3,000 'gethostbyname's at the same time in a commercial product. On > NT, I can create 3,000 threads and call 'gethostbyname' in every one. Not > pretty, but it works. > > On FreeBSD, I'm basically screwed. I'd have to write me own resolver > library to do the job. Licensing problems prevent me from using pretty much > every nice resolver library out there. The bind 8.x stuff doesn't have licensing issues; it allows multiple concurrent operations. It is merely that the 4.x resolved is wedged into libc that causes your problem. > > Completion ports are no more, and no less, than VMS AST's. Just > > like aio* in FreeBSD, and much of the POSIX crap that's passing > > for standards these days. > > > > They may make it easier to code, by calling your callbacks, but > > the idea that network buffers should be in user space instead of > > on the kernel side of the protection domain barrier is just > > plain nuts. > > They're on both sides in every implementation. It's just a matter of when > the borders get crossed. I disagree. I can turn around reads and writes in the kernel without taking the copy overhead. NFS does this, and a KLD that could do this for SAMBA and AFS, while not trivial, given the state of the FreeBSD VFS interface, the protocol stack incursions for routing of the specific packets, and the mbuf reference to buffer cache objects that would be required, is well within the realm of possibility. If anything, the ability to use the GPL'ed SAMBA code in the Linux kernel may well be the deciding factor for eventual FreeBSD vs. Linux SMB performance, the same as it was for Linux vs. FreeBSD NFS performance. > > The anti-NT sentiment wasn't mine. On equivalent hardware, it > > handily beats FreeBSD's SMB server performance (one of the major > > impetus' for the work Kirk is now doing). I've address some of > > that in another posting, from my experience optimizing a similar > > hosted server for NetWare on Solaris, UnixWare, Dell UNIX, VMS, > > and AIX. The problems are correctable, but require work to be > > done, and code to be committed. > > And that's good, because this kind of comparison is what spurs > development. Embarassing benchmark results have done a lot for > Linux's development lately. :) It seems that FreeBSD doesn't mind running around with its pants off with NT in the room, unless Linux is in the room. 8-). Let us hope that beating Linux is seen as a more worthy goal than beating NT apparently is... 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-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907151842.LAA29095>