Hal Murray <hmur...@megapathdsl.net>:
>
> e...@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>
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
