On Fri, Jul 1, 2011 at 10:13 AM, Bharat Joshi <[email protected]> wrote: > Please see in line. > > Thanks, > Bharat > > On Thu, Jun 30, 2011 at 1:43 PM, Masao Uebayashi <[email protected]> wrote: >> On Sun, Jun 26, 2011 at 10:13 PM, Bharat Joshi <[email protected]> wrote: >>>>> I am currently uing NetBSD 2.0 (plan to move to new one in some >>>>> time). I need to add more physical memory after it has already been >>>>> initialized once using uvm_page_physload. >>>>> >>>>> When I tried to call uvm_page_physload again with this new RAM >>>>> area, it paniced. I then found out that a flag 'VM_PHYSSEG_NOADD' in >>>>> vmparam.h for mips needs to be disabled. I removed this flag and then >>>>> things seems to have worked as expected. >>>>> >>>>> I want expert's opinion on whether this method of adding new >>>>> physical memory in UVM is the right (may be the only) way in NetBSD >>>>> 2.0. Please do let me know. >>>> >>>> That would work to some extent. Limitations: >>>> >>>> - Data structures are not protected with locks. >>>> >>>> - Metadata (vm_page array) is allocated in somewhere by malloc(), not >>>> in the newly added physseg. >>>> >>>> So, if it works for you on NetBSD 2.0, I'd say it's OK for you. ;) >>>> >>> >>> Thanks for your response. It worked for me as all my applications are >>> working fine. I have not stressed this yet so we will know more about >>> it in coming days. >>> >>> Let me tell my exact requirement. I have some memory after kernel that >>> is being used for some purpose. I want to free it back to physical >>> memory once that purpose has completed. So I disabled that flag and >>> allow uvm_page_physload to be called again. >>> >>> I was not sure so asked this on the list. Now I have another question. >>> "Is there any other better way of doing this?" >>> >>> Can we do something like as follows: >>> >>> 1. Pass avail_start in uvm_page_physload with an offset (start - >>> avail_start ) of the memory which needs to be added in physical memory >>> later. This will make sure that we have pages created for the whole >> >> I don't understand what "which needs to be added in physical memory >> later". Could you elaborate this? > > What I mean is that part of the physical memory which is being > currently used( when I call uvm_page_physload), will be added to the > total available physical memory once I do not need that part any more. > > Let me explain it with figures: This is how I am putting my kernel and > other images in the physical memory: > > 1. Kernel (of size 6 MB) start at the offset of 1 MB from start of > physical memory. > 2. After kernel, one image of size 5 MB is available. So end of this > image is at 12 MB offset. > 3. After the above image, I am adding another image of 20 MB. So end > of this image is at 32 MB offset. > > Now, when I call uvm_page_physload, I call it with 32 MB offset as > start and avail_start and 128 MB offset as end and avail_end (total > 128 MB memory is available). > > Now, after some-time, I want to release the 20 MB I am using in point > 3 above. So I call uvm_page_physload again with 12 MB offset as start > and avail_start while pass 32 MB offset as end and avail_end with the > same free-list.
So you have to ensure that the 20MB physseg (12MB .. 32MB) has all its pages back to the free list so that you can safely detach the physseg. I don't think NetBSD/UVM provides such functionality at the moment (detachment of physseg used for general purpose memory).
