Re: Query regarding adding physical memory after uvm_page_physload

[Bharat Joshi <bharat.josh%gmail.com@localhost>]

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.

I hope this clarifies your doubt.

Thanks,
Bharat

>> memory but only the ones available after avail_start is added as free
>> pages.
>> 2. Later find the pages for this memory (start to avail_start) and
>> call vm_page_free for each pages.
>>
>> I was thinking that such an API be available in uvm-page layer but
>> could not find one so not sure if something like the above can/should
>> be done.
>>
>> So it would be great if someone can tell me ways in which this can be
>> achieved in a better way.
>>
>> Regards,
>> Bharat
>>
>