Subject: Re: pmap l1pt allocation strategy
To: Chuck Cranor <email@example.com>
From: Jason R Thorpe <firstname.lastname@example.org>
Date: 11/29/2002 08:13:50
On Thu, Nov 28, 2002 at 09:42:31AM -0500, Chuck Cranor wrote:
> 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).
Hm. I had thought I removed it in a different commit, but I guess not.
Anyway... on the i386, I don't think PTP stealing was ever used for the L1
table ... in this case, the process was simply blocked doing the allocation,
which is essentially what the ARM pmap does ... it's just that the ARM is
a lot less likely to be able to dynamically allocate the L1 table because
it needs to be 4 contig pages with 16K alignment.
The reason PTP stealing was removed from the i386 pmap (and alpha pmap)
is because: Now that pmap_enter() is allowed to fail, there is no more
need for it; UVM will now go to sleep in a resource starvation situation
I know the argument can be made that, with PTP stealing, you're able to
hobble along in extreme starvation situations (you just make page faults
and whatnot extremely expensive in these situations). But you're really
only putting off the inevitable, because eventually you'll have to allocate
a page and there will be none available. It certainly didn't seem to justify
the added complexity (and associated locking complexity) that came with the
PTP stealing code.
-- Jason R. Thorpe <email@example.com>