On Tue, Jun 26, 2012 at 12:41 AM, Dave Hylands [off-list ref] wrote:

Hi Subbu,

On Mon, Jun 25, 2012 at 7:45 PM, Subramaniam Appadodharana
[off-list ref] wrote:
...snip...

quoted

quoted

However, if you call vmalloc and lets suppose that vmalloc just
happens to return 0xE0000000. The physical address of the first page
might be 0xD2345000.

What's important is that the physical pages which back up the vmalloc
area all come from the kernel direct mapped area. They won't ever be
backed by pages from high-memory. So the physical addresses will all
be in the range 0x40000000 thru 0x5FFFFFFF.

This is the one that I had a completely wrong understanding of!!!!!!!
I understand from the above statement that  the vmalloc'ed virtual

address

quoted

will _ALWAYS_  correspond to a  physical address from the lowmem region!

I

quoted

was under the impression that the carved out region for the vmalloc,
is the one that would back any vmalloc'ed virtual address, which is
absolutely wrong by what you are saying.

Actually, I was the one that was wrong. vmalloc pages can come from
low or highmem.

Thanks for clarifying! Not a problem.

Now this also means that increasing vmalloc inadvertently reduces lowmem.

quoted

Why is this designed such a way?

It may or may not depending on the amount of physical memory and the
size of the vmalloc space.

vmalloc space will normally increase vmalloc_end, which won't reduce
lowmem.
If the end can't advance any further, then I believe that the start
can be reduced. This will reduce lowmem, if the lowmem overlaps with
vmalloc memory.

Okay! got that!

quoted

Essentially, the idea that we increase vmalloc is because we expect more
memory to be consumed via vmalloc
calls, and hence we might need more physical address backing. But

increasing

quoted

vmalloc decreases low mem, which would also mean that we have less

backing.

quoted

Am I missing something here too :)?

No - that was my mistake.

No problem again. Thanks for correcting it!

--
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120626/65cea5bb/attachment.html