Subject: Re: pmap l1pt allocation strategy
To: David Laight <email@example.com>
From: Richard Earnshaw <firstname.lastname@example.org>
Date: 11/28/2002 10:55:40
> > But the fundamental problem is that there is no way to ask the paging
> > system to free up a 16K-aligned block of memory -- all you can ask for is
> > 4 pages, so we end up in the situation where the paging system thinks
> > there are enough free resources, but the vm system doesn't.
> To avoid a complete rewrite of the paging system, could you timeout
> and retry, asking the paging system for more free pages each time?
Not from within the pmap code, the pmap asks uvm for a 16k, 16k-aligned
chunk of memory, it's the uvm system that asks the paging system to
reclaim the memory. The paging system wakes up; decides that enough pages
are already available to fulfil the request and goes back to sleep again.
> Make fork should fail EAGAIN after a timeout as well?
It's too late to fail with EAGAIN at that point; state has been created.
Besides, the pmap has no way of indicating to UVM that it can't get a L1
table (which is why it has to sleep in this case).
> But swapping them (or stealing one from an idle process?)
> may be better.
> Thinking about the free list, I'm not sure keeping entries in case
> you can't allocate 1 would be an advantage.
> You would have the preserve the last entry for root, and probably
> for an interactive shell that isn't in a fork bomb...
> The freelist is (presumably) there to avoid the expensive allocate
> when running shell scripts (etc).
It should probably be done using the pool system rather than having our
own private stash, but yes that's the general idea. Plus, I think the
argument goes, if you've used that many L1s before, then you are likely to
again, so better make sure we hang on to some suitably aligned memory.
A final, brute-force approach to the problem might also be,
Find 4 (consecutive, 16k-aligned) physical pages that are not wired but
are used for user-space accesses, and 4 physical pages that are not
allocated; implement a uvm interface to forcibly migrate the physical
pages to the new pages and then to release the freed up pages as a chunk;
since the virtual addresses never change, and since they aren't wired down
in any way, the system should be oblivious to the fact that the memory has