Date: Fri, 26 Sep 2014 10:41:12 -0700 From: Warner Losh <imp@bsdimp.com> To: Svatopluk Kraus <onwahe@gmail.com> Cc: freebsd-arch@freebsd.org Subject: Re: vm_page_array and VM_PHYSSEG_SPARSE Message-ID: <2F2CA5C3-3F0A-4F7D-B9C5-E78DC9E9F92A@bsdimp.com> In-Reply-To: <CAFHCsPWkq09_RRDz7fy3UgsRFv8ZbNKdAH2Ft0x6aVSwLPi6BQ@mail.gmail.com> References: <CAFHCsPWkq09_RRDz7fy3UgsRFv8ZbNKdAH2Ft0x6aVSwLPi6BQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Sep 24, 2014, at 5:27 AM, Svatopluk Kraus <onwahe@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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUJaU4AAoJEGwc0Sh9sBEAAi4QAIZ+XlJ+3BWdd3GJq1mOCK2N fp/re18Wrp8aNqPsBB4xxeO4Ju18+1tuO/BP+4zvuBmnBt5YkWwXaDUpZlSYZE5F BsjOBOvAV1COJSYhavxFOCHu7Uguv5oOqPkcAiW8nDmPeCcWzU0T8aVZOQ56ZW9r 2MCadr7nzJNWS3hsZ2FWNZmDxeHhY2+t+NSF1s7oL5WrzGTYzlgFvbQhtgMx1vzJ pdrUsJXqMnWk2b1R8OveN58gGCDJFy2kmHQGLsetCe4A0XI4uKom+8gsPgHEbH6Z Hhhe4x82CKXVHhs9fwvV862c905lI4cPRLcbPSx2jUAHFdCxZeQxHJFBuXTYhfnp 3FWrMbAywCKlOi0WiZgLnjYo56dlKFKhavTbjMIBd05LC7rwo8CnUJPEjHNDuhVR NpGQDE4jrSp5j4haWEDroyu1BNH4QpwGsbbk4bWMJUJLBOLJHNvff311z6yfwRSr PFsxO09HAZaXcSd9b9BRrfdnKI1AJ6iGxQaJ2cA7wgz/pdGO5ml+BOsOKQxFdS7p KIGDMmJjHbp0mzS2cKiaGDbxIbbniczS8eYPwDxIPwIGHTQ103cosSC3/IUCkCPt /5Em+DlCu+DP3Gfy9kItHhCXdb3lIIw4YK7M3u37E36ayaH2+7dAwoQwUkkm0ODn lM70Nzw63G5nBwQqvWhi =ATk/ -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2F2CA5C3-3F0A-4F7D-B9C5-E78DC9E9F92A>