Use of pool servers reveals unacceptable crash rate in async DNS

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> > In this case, we have two possible complexity-reducing fixes.  One is to
> > drop the memlock feature entirely.  The other is to drop the buggy homebrew
> > asynchronous-DNS lookup from Classic and use libc's.
> 
> Dropping memlock is an interesting idea.  I can't think of any place where it 
> is required today but my crystal ball for what we will need tomorrow has 
> never been very good.

Crypto security *might* be it.  I'll wait for Daniel to weigh in once
he's done climbing mountains or whatever.

> What would you do if we discovered a case where we wanted it?

Cry a lot.  Then add logic to force synchronous DNS when memlocking is
selected, and document this as a workaround for a bug we haven't fixed yet.

> We could try simplifying things to only supporting lock-everything-I-need 
> rather than specifying how much.  There might be a slippery slope if 
> something like a thread stack needs a sane size specified.

I'm not intimate with mlockall, but it looks like it works that way now.

	if (do_memlock) {
		/*
		 * lock the process into memory
		 */
		if (!dumpopts &&
		    0 != mlockall(MCL_CURRENT|MCL_FUTURE))
			msyslog(LOG_ERR, "mlockall(): %m");
	}

> Is there a simple way to count page faults for a process?  Or measure swapped 
> out data and/or code that isn't swapped in?

I don't know.  I can do some research, but I'm not sure "enough page faults
to merit memory locking" would be a well-defined threshold even if I knew how
to count them.

> I don't think your use-libc approach will be as simple as you would
> like.  It's not available on NetBSD or FreeBSD.  Maybe I just didn't
> look in the right place.  It's not in netdb.h where it is for Linux.

I believe you're right that these platforms don't have it.  The question is,
how important is that fact?  Is the performance hit from synchronous DNS
really a showstopper?  I don't know the answer.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>