tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Query regarding adding physical memory after uvm_page_physload

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

Home | Main Index | Thread Index | Old Index