LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)
-   -   Memory management in 32 bit systems (https://www.linuxquestions.org/questions/linux-software-2/memory-management-in-32-bit-systems-4175448858/)

barunparichha 02-06-2013 06:09 AM

Memory management in 32 bit systems
 
Let's say I have a 32 bit machine (4GB virtual memory space) and 16 GB RAM (34 bit address needed to address all locations).

As per linux OS 4GB virual space = 3GB user space + 1GB kernel space.
Only kernel space address match directly to physical memory.

Here I have 2 questions:
Code:

1. whether user space address to be mapped to kernel space address before accessing my RAM from user space application.
Code:

2. with 32 bit machine I can maximum access 4GB of RAM, what happens to rest 14GB ?? How it's taken care by memory manager or page manager ??

syg00 02-06-2013 06:16 AM

1). Nope.
Kernel addresses are real - no page translation. User-space uses page table to map virtual address to real address (when resident in real).
2). PAE. See http://en.wikipedia.org/wiki/Physical_Address_Extension

johnsfine 02-06-2013 07:57 AM

1) Question is so confused, I can't guess what you are trying to get at. But.
Quote:

Originally Posted by syg00 (Post 4885439)
Kernel addresses are real - no page translation. User-space uses page table to map virtual address to real address (when resident in real).

No. Some obscure architectures running Linux act that way, but x86 certainly does not.
All addresses (kernel and user) go through page translation.

Linux was designed with the idea that virtual address space is larger than physical ram (back when 1GB of ram was too expensive to put in a single computer). So it was convenient to map all of physical ram to a contiguous subset of kernel virtual addresses, so a physical address can be accessed by just adding an offset. Current 32-bit Linux maps only a small part of physical ram that way. Certain kernel data structures are restricted to that small part of physical ram.

2). All addresses (kernel and user) go through page translation.

Every 32-bit virtual address is split by the CPU into a 20-bit virtual "page frame number" and a 12 bit offset within the page. Then the 20-bit number is looked up in a hardware translation system (translation look aside buffer) to produce a 24-bit physical PFN. The 24-bit PFN and original 12-bit offset are combined to produce the 36-bit physical memory address.

The kernel maintains a hierarchical set of page tables (for each process). When any 20-bit virtual PFN is missing from the "translation look aside buffer" hardware, the CPU automatically looks that PFN up in the page table structure to use and to copy into the TLB. If the translation is disabled in the page table structure, the CPU "faults" into kernel code to take appropriate action (such as physically reading in a page from a file mapping).

Back to the actual question (2): At any one moment (in any single core or hyperthread), the TLB and page table system can map at most 1048576 4KB pages (total 4GB) but that 4GB may be scattered anywhere through the 64GB physical address space. When the kernel switches to a different process, it flushes the TLB system and it switches to a different page table structure.

Each hyperthread has its own page table pointer. So if you had a 4 core CPU with hyperthreading enabled, there are eight independent page table pointers so eight different software threads could be using eight different 4GB subsets of the 64GB physical space.

By hardware design, each of those page tables hierarchies is totally independent. By Linux design (for 32-bit x86) all of those page table structures overlap and share their top 1GB of mappings. So kernel addresses are the same in every process address space.

One extra detail: There is actually an alternate translation method that can be mixed in. In that method only the top 11 (not 20) bits of virtual address are translated to the top 15 (not 24) bits of physical address. The bottom 21 bits of virtual address pass untranslated to the bottom 21 bits of physical address (just as normally the bottom 12 bits pass through untranslated). That is a more efficient system for use when a large area of physical memory is used contiguously in virtual address space, such as the Linux mapping of a big contiguous chunk of physical memory to be most of the kernel virtual space.

barunparichha 02-07-2013 03:02 AM

Syg00 and Johnsfine,

I did not know that higher portion of virtual memory is process specific. So the same virtual address will map to different physical memory when it contetxt switches to a different process.

Thanks for your detailed clarifications.

johnsfine 02-07-2013 07:57 AM

Quote:

Originally Posted by barunparichha (Post 4886068)
I did not know that higher portion of virtual memory is process specific.

It is the portion (3GB) with lower virtual addresses that Linux makes process specific. So your use of "higher" might be a misunderstanding (but I'm not sure what you meant by higher).

Quote:

So the same virtual address will map to different physical memory when it contetxt switches to a different process.
Yes.

chrism01 02-07-2013 07:28 PM

@OP; do note that regardless of the memory addressing details, if you only have a 32bit OS and want to use more than the base 4GB of RAM, you'll need a PAE kernel as per syg00's 2nd point.
This is an OS requirement.
In other words, a 32bit OS cannot see beyond 4GB, unless you use eg PAE kernel.


All times are GMT -5. The time now is 04:59 PM.