vm_page_array and VM_PHYSSEG_SPARSE

[Warner Losh]

On Sep 24, 2014, at 5:27 AM, Svatopluk Kraus <onwahe at gmail.com> wrote:

> Hi,
> 
> I and Michal are finishing new ARM pmap-v6 code. There is one problem we've
> dealt with somehow, but now we would like to do it better. It's about
> physical pages which are allocated before vm subsystem is initialized.
> While later on these pages could be found in vm_page_array when
> VM_PHYSSEG_DENSE memory model is used, it's not true for VM_PHYSSEG_SPARSE
> memory model. And ARM world uses VM_PHYSSEG_SPARSE model.
> 
> It really would be nice to utilize vm_page_array for such preallocated
> physical pages even when VM_PHYSSEG_SPARSE memory model is used. Things
> could be much easier then. In our case, it's about pages which are used for
> level 2 page tables. In VM_PHYSSEG_SPARSE model, we have two sets of such
> pages. First ones are preallocated and second ones are allocated after vm
> subsystem was inited. We must deal with each set differently. So code is
> more complex and so is debugging.

That would be nice. Right now the memory allocation code early in the ARM code
is very simplistic on all the platforms I’ve looked at: we get a base address and
just increment it as we allocate the page tables, etc.  It would be straight forward
to add calls to note all of these pages.

> Thus we need some method how to say that some part of physical memory
> should be included in vm_page_array, but the pages from that region should
> not be put to free list during initialization. We think that such
> possibility could be utilized in general. There could be a need for some
> physical space which:
> 
> (1) is needed only during boot and later on it can be freed and put to vm
> subsystem,

I don’t think we have any pages that are like this. The pages that could be
freed today are just wasted.

> (2) is needed for something else and vm_page_array code could be used
> without some kind of its duplication.
> 
> There is already some code which deals with blacklisted pages in vm_page.c
> file. So the easiest way how to deal with presented situation is to add
> some callback to this part of code which will be able to either exclude
> whole phys_avail[i], phys_avail[i+1] region or single pages. As the biggest
> phys_avail region is used for vm subsystem allocations, there should be
> some more coding. (However, blacklisted pages are not dealt with on that
> part of region.)

Usually just not putting them into the free pool would be enough to keep the
vm’s hands off of them. What are you proposing over that?

> We would like to know if there is any objection:
> 
> (1) to deal with presented problem,
> (2) to deal with the problem presented way.
> Some help is very appreciated. Thanks

I generally like the idea, so long as the vm_page_array doesn’t eat a lot of
memory. In the early days, we went with SPARSE, I believe, to avoid having
huge arrays for those platforms whose memory started at 0xfxxxxxxx or
0xexxxxxxx… But memory here is a bit hazy...

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20140926/3e39d018/attachment.sig>