In message <1137379094.456166.14292.nullmailer@yamt.dyndns.org>YAMAMOTO Takashi
 writes
>> One really *has* to mlock() the lookup data into memory, because our
>> VM page-scanner is *pitifully* weak for applications like this.  (I
>> measured 7+ hrs elapsed time on NetBSD-3.0/amd64, non-mmaped, vs. 2
>> hrs on Linux, without any special mlock() in the Linux code).
>
>non-mmaped?

Sorry, non-mlock()ed. the rest makes sense.

[...]

>there is no cheap way to calculate "lockdelta" there, afaik.

Then maybe the current test should be removed, because it's  wrong?


>maybe we can check the limit on fault_wire path instead.
>in this way, i think we can also fix "threads vs rlimit" problem.

Sorry, I don't see how that helps, nor do I see the threads problem.
Comments in uvm_map_pageable seems to say that uvm_fault_wire() is
called for each page being wired. Does it have sufficient state to
check the limits and return an appropriate error code back to userland?

Or am I missing something to do with threads?  If we need to enforce
per-process-rlimits against per-thread calls, then surely we must give
those uvm operations serialized semantics across all threads in a
process, no?