<br><div class="gmail_quote">On Fri, Mar 15, 2013 at 12:31 PM, Arun KS <span dir="ltr"><<a href="mailto:getarunks@gmail.com" target="_blank">getarunks@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 Niroj,<br>
<div class="im"><br>
On Wed, Mar 13, 2013 at 3:16 PM, Niroj Pokhrel <<a href="mailto:nirojpokhrel@gmail.com">nirojpokhrel@gmail.com</a>> wrote:<br>
</div><div><div class="h5">> Hi All,<br>
><br>
> I have been studying Memory Management in linux. But I am confused with the<br>
> division of different ZONE. The use of ZONE_DMA and ZONE_NORMAL is fine. But<br>
> I am confused with ZONE_HIGHMEM, if the system is 32 bit then why can't it<br>
> map 4GB memory (2^32). I had thought that ZONE_NORMAL was for the kernel<br>
> usage so directly mapped and ZONE_HIGHMEM for the user process and is not<br>
> directly mapped to facilitate virtual addressing. But I know I am not<br>
> getting something right. While going through Ch - 15 of Rubini's Linux<br>
> Device Driver (Memory Management and DMA) I came across following line<br>
><br>
> "a 64-bit architecture such as Intel’s x86-64 can fully map and handle<br>
> 64-bits of memory.Thus, x86-64 has no ZONE_HIGHMEM and all physical memory<br>
> is contained within ZONE_DMA and ZONE_NORMAL." So, if it can be directly<br>
> mapped why not in 32 bit architecture.<br>
><br>
> I am really confused. Please Help. Thanking you in Advance<br>
<br>
</div></div>On a 1:3 VM split, kernel has 1GB of virtual space.<br>
This 1GB kenel VM is split accross I/O mapped registers, Interrupt<br>
vector table, VMALLOC area<br>
and your system memory(ie RAM).<br>
<br>
For example let's say,<br>
I/O mapped register + VMALLOC area + vector table = 200MB.<br>
So virtual space left for System memory = 1024MB - 200MB = 824MB.<br>
Now consider you have 1GB of System memory(RAM). How will you use it?<br>
<br>
Two ways<br>
1) You can change VM split(user space:kernel space) to 2:2, or<br>
2) Use High Mem.<br>
<br>
If using 2:2 VM split, then your kernel space is 2GB and you have<br>
plenty of space to map system memory.<br>
<br>
If High mem, you will have a temporary mapping to High mem area. This<br>
mapping is usually used from vmalloc area.<br>
High mem, in our case is 200MB( 1024MB of total ram - 824 MB which is<br>
already mapped to kernel virtual space)<br>
Permanent mapping also is available from high mem. But this VM space<br>
will be limited in size(eg 2MB). This is know as pkmappings.<br>
<br>
For more information have a look at page 253 of Linux kernel<br>
development 3rd edition- Robert Love.<br>
<br>
All this complexity will go into vents when 64 bit architecture comes because,<br>
2^64 = 16ExtraByte(EB)<br>
You have 16EB of virtual space compared to 4GB of virtual space for 32<br>
bit architecture.<br>
<br>
HTH<br>
<span class="HOEnZb"><font color="#888888"><br>
Arun<br>
</font></span><div class="HOEnZb"><div class="h5">><br>
><br>
> Yours,<br>
> Niroj Pokhrel<br>
><br>
> _______________________________________________<br>
> Kernelnewbies mailing list<br>
> <a href="mailto:Kernelnewbies@kernelnewbies.org">Kernelnewbies@kernelnewbies.org</a><br>
> <a href="http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" target="_blank">http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
><br>
</div></div></blockquote></div><br><br>Thanks Arun,<br>That explains a lot and I almost understand it but still have a doubt.<br>So, when we create Kernel thread why do they need the page tables (though the mm points to NULL, the kernel thread uses memory descriptor of whatever processes ran earlier, right ??). First, we already have 896 MB of directly mapped space ( and I think we don't need page table entries for this one) and if it is for the HIGH_MEMORY area then doesn't the memory gets deallocated and hence the page table entries when the process exit so what info exactly is obtained by the kernel thread from that memory descriptor's page table entries. Thanking you in advance.<br>
<br>Yours,<br>Niroj Pokhrel<br>