Date: Sat, 27 Sep 2014 10:32:19 +0200 From: Svatopluk Kraus <onwahe@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arch@freebsd.org Subject: Re: vm_page_array and VM_PHYSSEG_SPARSE Message-ID: <CAFHCsPU1W7mmEQCiBtwzyg6Y%2Be8tKGpcYEf2W-jCMBKm-7U13Q@mail.gmail.com> In-Reply-To: <2F2CA5C3-3F0A-4F7D-B9C5-E78DC9E9F92A@bsdimp.com> References: <CAFHCsPWkq09_RRDz7fy3UgsRFv8ZbNKdAH2Ft0x6aVSwLPi6BQ@mail.gmail.com> <2F2CA5C3-3F0A-4F7D-B9C5-E78DC9E9F92A@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 26, 2014 at 7:41 PM, Warner Losh <imp@bsdimp.com> wrote: > > 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 su= ch > > pages. First ones are preallocated and second ones are allocated after = vm > > subsystem was inited. We must deal with each set differently. So code i= s > > 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=E2=80=99ve 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 som= e > > physical space which: > > > > (1) is needed only during boot and later on it can be freed and put to = vm > > subsystem, > > I don=E2=80=99t think we have any pages that are like this. The pages tha= t could be > freed today are just wasted. > I'm not sure that I understand the second sentence in the scope of the first one. However, I can imagine that some data which comes from loader, is saved on memory, cannot be processed before vm subsystem initialization, and could be free afterwards, it is good example for (1). Anyhow, it's not a case of today probably. > > > (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 tha= t > > part of region.) > > Usually just not putting them into the free pool would be enough to keep > the > vm=E2=80=99s hands off of them. What are you proposing over that? > If you are asking about case (2), then I just think that it could be convenient to have a possibility to reuse vm_page_array's functions for memory which is not for vm's hands. Again, it's about another possibility which would arise if there will be a method how to put some memory region into vm_page_array but off of vm subsystem. > > > 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=E2=80=99t e= at a lot > of > memory. In the early days, we went with SPARSE, I believe, to avoid havin= g > huge arrays for those platforms whose memory started at 0xfxxxxxxx or > 0xexxxxxxx=E2=80=A6 But memory here is a bit hazy... > > Warner I already have had that in my mind. What I've presented here eats only as much memory as is really needed and nothing more. I like the idea about using dump_avail instead of phys_avail for vm_page_array initialization and segmentation, but it eats more (but not much more). Svata
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFHCsPU1W7mmEQCiBtwzyg6Y%2Be8tKGpcYEf2W-jCMBKm-7U13Q>