Subject: Re: 4MB pages?
To: Jason R Thorpe <email@example.com>
From: Eduardo Horvath <firstname.lastname@example.org>
Date: 09/06/2000 09:52:30
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.