On Wed, 6 Sep 2000, Jason R Thorpe wrote:

> On Wed, Sep 06, 2000 at 08:16:42AM -0700, Matt Thomas wrote:
> 
>  > For memory intensive (mmap large files, etc.) programs, I was wondering whether
>  > it would be useful to have another uvm free page area which contains free 4MB
>  > blocks.  As memory gets freed, as a complete 4MB block is freed it would be
>  > moved to the free 4MB list.
> 
> That's possible... I haven't really looked at that, yet.
> 
>  > 4MB page table entries would be real useful for mapping framebuffers as 
>  > well but
>  > that requires a[nother] change to the driver mmap interface.
> 
> Yes, I agree.  I'd like to introduce a pmap_enter_range() and a set of
> macros that UVM can use to properly align the address, etc.  That's a
> ways off yet, tho.  In particular, dealing w/ e.g. PV entries is going
> to be tricky.  At first, limiting it to unmanaged pages (like e.g. frame
> buffers, or memory that has been stolen to be managed by something else,
> like, say, pools) seems reasonable.

Actually, the pmap changes should be quite simple.  pmap_enter() could
take a page list or range of pages and search for the largest page size
they fit in.  PV entries or TTEs would have some bits indicating their
size.  If a pmap operation is issued on the middle of a bigger page it
simply calculates the real beginning of the page and executes the
operation on all the sub-pages.

The real problems are deciding when to split a page, either for
ref/mod accounting because a portion has been touched, or there are
multiple mappings of only portions of a large page.  For this we need UVM
support, which is a nastier issue.

Eduardo Horvath