Re: Regarding virtual address space of the kernel...

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

 



Hi Naman,

On Fri, Jun 17, 2011 at 1:34 AM, Naman shekhar Mishra
<namanshekharmishra2@xxxxxxxx> wrote:
> I've been trying to understand this for a while with little success so any
> help would be hugely appreciated...
> Suppose I have 512 MB of physical RAM available in the system. The top 1 GB
> part of the 4 GB virtual address space maps *directly* starting from the 0
> physical address (mapped by kernel). (Question 1) **Doesn't that mean that
> the physical RAM is not enough to support this  mapping (I mean, only 512 MB
> will be directly mapped be the kernel. Moreover, no physical space will be
> left for user space mapping)? And even if I have 1 GB of physical RAM
> installed, where would all the processes get mapping from since this this 1
> GB will be mapped in the address space of the kernel? **

Let's suppose that you're using an ARM (just because that's what I'm
familiar with), and further lets' suppose that yours 512 Mb of memory
occupies 512 MB starting at address 0x40000000 (rather arbitrary - but
I wanted to pick something that wasn't zero).

So your physical memory will be at 0x40000000 - 0x5fffffff
The kernel will map the 512Mb virtual space 0xc0000000-0xdfffffff to
the 512 Mb physical space 0x40000000-0x5fffffff.

When a user mode process starts, the kernel will allocate pages from
it's memory, and setup additional virtual mappings into that memory.

> I read in a book:
> "The address space after PAGE OFFSET is reserved for the kernel and
> this is where the complete physical memory is mapped (eg. if a system
> has 64mb of RAM, it is mapped from PAGE OFFSET to PAGE OFFSET
> + 64mb)."

That's true, when the physical memory fits into that space. There are
also alternative mappings where you can change the split. By default
userspace gets 3Gb virtual space, and kernel gets 1Gb. You can also
2/2 and 1/3 splits as well.

> (Question 2, somewhat related to Q1)**Does this mean that no physical memory
> is left to be mapped by user space virtual memory (i.e. if all physical
> memory is mapped by address above PAGE_OFFSET, what is mapped by address
> below PAGE_OFFSET)?**

No the kernel allocates pages from its memory to give to each
user-mode process. This page has a reasonable picture:
<http://www.xml.com/ldd/chapter/book/ch13.html>

The memory starting at PAGE_OFFSET is what are being referred to as
"kernel logical addresses".

user pages, and additional kernel memory (allocated using kmap/kunmap)
can use memory beyond the "logical space".

> (Question 3)**Also, why can't all memory, (PAGE_OFFSET to PAGE_OFFSET + 1
> GB) be mapped to this 64 MB. After all pages can be swapped out and new
> pages can be brought in.

Swapping only works when you have external storage to swap to. Many
devices running linux (like your typical Android phone) have zero
swap. I'm also pretty sure that only user-mode pages are swapped.

When you're using swap, you can have more virtual memory in use than
physical memory. In your example, if we had 64 Mb of physical memory
and say 512Mb of virtual memory allocated. 64 Mb of the 512 Mb would
be mapped to physical pages, and the remainder would be mapped to
"swap pages" located on some external device. Accessing one of the
swap pages would cause a page-fault and the kernel would need to
swap-out one of the physical pages and then swap in the page which
caused the page fault.

> (Question 4)**Also, when we say that kernel can map 896 MB (ZONE_NORMAL),
> does this 896 MB refer to virtual space or physical space?**

The 896 Mb is the limit on the "kernel logical" memory space, when you
use a 3Gb user/1Gb kernel split.

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

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux