Re: Query regarding adding physical memory after uvm_page_physload

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Fri, Jul 1, 2011 at 10:13 AM, Bharat Joshi <bharat.josh%gmail.com@localhost> 
wrote:
> Please see in line.
>
> Thanks,
> Bharat
>
> On Thu, Jun 30, 2011 at 1:43 PM, Masao Uebayashi 
> <uebayasi%gmail.com@localhost> wrote:
>> On Sun, Jun 26, 2011 at 10:13 PM, Bharat Joshi 
>> <bharat.josh%gmail.com@localhost> 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).