Skip site navigation (1)Skip section navigation (2)
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: <http://docs.FreeBSD.org/cgi/mid.cgi?199907151842.LAA29095>