Subject: Re: bug in wired accounting [[was Re: Can't lock even 4GB on system
To: None <jonathan@dsg.stanford.edu>
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
List: tech-kern
Date: 01/16/2006 11:38:14
> 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?
you are talking about mmaped regions in the rest of the mail, aren't you?

does "without any special mlock() in the Linux code" imply
"with special mlock in netbsd"?  do you mean 7+ hours with mlock, and
even worse without mlock?

> wiredmax is system-wide.  So for a shared region being mapped and
> locked multpile times, the code should instead compute something like:
> 
> 	 lockdelta = atop(size) - pmap_wired_count(vm_map_pmap(map))
> 
> and use lockdelta as the appropriate size limit for wiredmax.
> 
> I can see arguments either way for the per-process limit, but since
> wiredmax is the documented "system-wide" limit, wiredmax checks should
> apply to the actual, system-wide locked memory, i.e., the delta.

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

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

YAMAMOTO Takashi