On Fri, Dec 07, 2001 at 07:53:17AM +1100, Darren Reed wrote:

 > What about sparc or ultrasparc?  I've seen recent Solaris9 stuff on
 > their public web pages saying they now support this.

I only listed a few examples.  Most modern CPUs support this in some
form.

 > This is fine if you want to provide hints, but what about something like
 > VM_PMAP_BESTFIT?  ie. make it search forwards rather than backwards so
 > that it can be used without particular knowledge of what's in that array.
 > It strikes me that providing hints is going to be somewhat architecture
 > dependant, too, as PMAP_PAGESIZE(1) might be 4M for i386 but 4M might
 > be PMAP_PAGESIZE(5) on some other architecture (hypothetical).

Right.  See what I said -- it's sorted in ascending order, so you start
at the end, if the page size is too large, you go on to the next smallest,
etc., and once you find one, you try to allocate VM space aligned to that
size.

It's not the sizes at each position of the file that matters ... it's the
well-defined order of the entries in the table.

 > Also, please excuse my ignorance on pmap & va, can it used mixed allocation
 > to fill a request?  So that if I ask for (say) 4.5MB of va it looks and says
 > "ooh, I can do that with 1*4MB and 128*4k and get a perfect fit!" rather
 > than doing 2*4Mb and wasting 3.5MB of virtual memory?  At what point does
 > it decide to waste VA for pmap entries?  (Research paper on this?)

This is an implementation detail that I have not yet addressed.  Certainly,
if the VA allocator finds a size that is larger than some large page size,
it could choose to attempt allocation based on that size.

Like I said, it's only for specifying the ALIGNMENT, not the size of the
allocation.  Of course you can map a 4M chunk and N 4K chunks next to
each other to cover the range...

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>