Subject: Re: pmap l1pt allocation strategy
To: None <email@example.com>
From: Chuck Cranor <firstname.lastname@example.org>
Date: 11/28/2002 09:42:31
In article <20021128063539.GA19568@marie.pcnet>, <email@example.com> wrote:
>since I've upgraded to NetBSD-1.6_STABLE as of this weekend, I'm running
>into l1ptwait much more often than before.
>I've increased PMAP_STATIC_L1S to 128 and still get one or three per evening.
>The only alternative to make this pmap stable would be to use a VAX-like
>16kB VM pages with 4KB mmu pages strategy, which naturally ensures that we
>never run out of aligned 16kB blocks.
actually, the way i intended for this sort of problem to be handled
is that if you cannot get a L1 from the normal places, then you should
"steal" one from another pmap (or even steal it from yourself).
this used to be quite clearly documented in the i386 pmap.c, but
Jason seems to have silently removed:
static struct vm_page *pmap_steal_ptp(obj, offset)
from i386 pmap.c in rev 1.117 (the log message misleadingly says
"Just garbage-collect the #if 0'd pmap_transfer() stuff." ... but
the diffs actually delete this function).
if the arm pmap had this sort of function, then you would not
be having the problem you are having now. basically you are taking
advantage of the fact that the pmap layer is free to throw away
information if it needs to reallocate memory.