Hi Dave,<div><br>Thank you for taking your time to provide this example. This is indeed very insightful.</div><div><br><div class="gmail_quote">On Mon, Jun 25, 2012 at 7:41 PM, Dave Hylands <span dir="ltr"><<a href="mailto:dhylands@gmail.com" target="_blank">dhylands@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Subbu,<br>
<br>
...snip,,,<br>
<div>>> __pa only works on kernel direct addresses.<br>
>><br>
>> __pa doesn't work on the addresses from vmalloc<br>
>><br>
>> Using __pa on VMALLOC_START or VMALLOC_END doesn't really make sense.<br>
>> If there were any physical memory there, it would be highmem.<br>
>><br>
> Okay, but my intention was to just print out the pa for the VMALLOC_START<br>
> and END, just to know where they are.<br>
> And I thought they will work. no?<br>
<br>
</div>You'll get some numbers, but they're meaningless.<br>
<br>
Let's take a concrete example (using ARM mappings)<br>
<br>
Suppose your machine has 1 GB of RAM with a physical addresses of<br>
0x40000000 thru 0x7FFFFFFF<br>
<br>
Let's suppose that PHYS_OFFSET = 0xC0000000<br>
Let's suppose that VMALLOC_START is set to 0xE0000000 and VMALLOC_END<br>
is at 0xEFFFFFFF (256 Mb)<br>
<br></blockquote><div>Agreed! </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So what we have is that memory from 0xC0000000 thru 0xDFFFFFFF (512<br>
Mb) is kernel direct mapped memory and maps to physical addresses<br>
0x40000000 thru 0x5FFFFFFF<br>
<br></blockquote><div>Agreed </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Physical memory from 0x60000000 thru 0x7FFFFFFF (512Mb) is considered<br>
high-mem. For the most part this is only usable by user-space. From<br>
kernel space, you need to use the kmap/kunmap functions to even access<br>
the memory.<br>
<br></blockquote><div>Agreed </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you use __pa(VMALLOC_START) you'll ALWAYS (with the above example)<br>
get 0xE0000000.<br>
Calling __pa(VMALLOC_END) would return 0xEFFFFFFF which is some<br>
address from the middle of high-memory, essentially a meaningless<br>
number.<br>
<br></blockquote><div>Agreed this one too!!!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
However, if you call vmalloc and lets suppose that vmalloc just<br>
happens to return 0xE0000000. The physical address of the first page<br>
might be 0xD2345000.<br>
<br>
What's important is that the physical pages which back up the vmalloc<br>
area all come from the kernel direct mapped area. They won't ever be<br>
backed by pages from high-memory. So the physical addresses will all<br>
be in the range 0x40000000 thru 0x5FFFFFFF.<br>
<br></blockquote><div>This is the one that I had a completely wrong understanding of!!!!!!!</div><div>I understand from the above statement that the vmalloc'ed virtual address will _ALWAYS_ correspond to a physical address from the lowmem region! I was under the impression that the carved out region for the vmalloc,</div>
<div>is the one that would back any vmalloc'ed virtual address, which is absolutely wrong by what you are saying.</div><div><br></div><div>Now this also means that increasing vmalloc inadvertently reduces lowmem. Why is this designed such a way?</div>
<div>Essentially, the idea that we increase vmalloc is because we expect more memory to be consumed via vmalloc</div><div>calls, and hence we might need more physical address backing. But increasing vmalloc decreases low mem, which would also mean that we have less backing. </div>
<div>Am I missing something here too :)?</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You can use vmalloc_to_pfn to return the PFN of the page which is<br>
backing a vmalloc'd virtual address. (if the physical address of<br>
0xE0000000 was 0xD2345000, then the pfn would be 0xD2345, assuming 4K<br>
pages).<br></blockquote><div>Agreed on this too! Thanks again for your time and patience.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div><br>
--<br>
Dave Hylands<br>
Shuswap, BC, Canada<br>
<a href="http://www.davehylands.com" target="_blank">http://www.davehylands.com</a><br>
</div></div></blockquote></div><br></div>