Thank you so much !! On Sun, Mar 15, 2015 at 8:48 PM, Arun KS <[email protected]> wrote:
> > On Mar 15, 2015 8:27 PM, "Sunny Shah" <[email protected]> wrote: > > > > Hi Arun, > > > > Thanks for that excellent explanation. It's more or less clear to me now. > > > > However, quoting what you said: > > > > Because we have plenty of kernel virtual > > address(3GB) and can easily map 2GB of RAM in to it. > > > > Why should we have to map the whole RAM into the KVA? Shouldn't it be > only LOW_MEM? > > We dont need to. I was just telling we can do that aswell. When you go > with 2:2 split, you are changing user space virtual memory layout. Which > will bring in lot if other problems. So very common approach is to use high > mem. > > > > > I also read on a stack overflow thread that LOW_MEM is memory that is > permanently mapped into KVA, while HIGH_MEM is mapped as required. Is this > true? > Absolutely > > Thanks, > Arun > > > > > Thanks, > > Sunny > > > > On Sun, Mar 15, 2015 at 1:17 PM, Arun KS <[email protected]> wrote: > >> > >> Hello Sunny, > >> > >> On Sat, Mar 14, 2015 at 8:25 PM, Sunny Shah <[email protected]> > wrote: > >> > Thank you guys! > >> > > >> > I have two more questions from your replies: > >> > > >> > I thought I had understood HIGH_MEM and LOW_MEM, but it appears I was > wrong. > >> > Does the concept of high memory/low memory correspond to physical > address > >> > space or virtual address space? Also, does LOW_MEM always have to be > 1 GiB > >> > maximum? > >> > >> Physical memory is divided into HIGH_MEM and LOW_MEM. > >> Why do we need two memory? To understand this, we need to know who > >> all are consumers of kernel virtual address(KVA) which is limited to > >> 1GB(in case of 3:1 split). > >> 1. low mem( physical ram which has linear mapping to KVA). > >> 2. IO memory address(for eg a DMA controller registers, Memory > >> controller register, etc). When MMU is enabled all the address > >> generated by the cpu are virtual address. Hence io memory should have > >> a valid virtual to physical memory mapping. > >> 3. Vmalloc address space. A dynamic kernel memory allocation > >> mechanism, which only guarantees continuity in virtual address space. > >> 4. Persistent kernel map. (if kernel want to use HIGH memory, it maps > >> high memory to this portion of virtual address). > >> 5. vector table. > >> > >> Let me give a rough calculation for a better understanding. Lets say a > >> system with configuration as follows, > >> 2GB of physical RAM, 40 MB of physical io address space, 240 MB of > >> vmalloc address space, 32 MB for persistent kernel map > >> The maximum RAM which can be mapped as low mem = 1GB - (40 MB + 240 MB > >> + 32MB) = 712MB. > >> > >> Rest of RAM 1336MB( 1GB - 712MB) will fall as HIGH_MEM. > >> > >> Now how system uses HIGH memory. Major user of HIGH mem is user space > >> code. Kernel directly maps high mem to user space virtual address. > >> Hight mem is also used by kernel though PK mappings. Even vmalloc > >> allocation can also fall from HIGH mem region. > >> > >> Now if we decides to use 1:3 user space to kernel space split, high > >> memory is not required. Because we have plenty of kernel virtual > >> address(3GB) and can easily map 2GB of RAM in to it. > >> > >> HTH. > >> > >> Thanks, > >> Arun > >> > >> > For a RAM of 896 MiB - 4096 MiB, the book says: > >> > "In this case, the RAM cannot be mapped entirely into the kernel > linear > >> > address space. The best Linux can do during the initialization phase > is to > >> > map a RAM window of size 896 MB into the kernel linear address space." > >> > > >> > Why is there a need to map the whole RAM into the kernel space (the > usage of > >> > the word "entirely") ? Shouldn't it be only LOW_MEM ? Or am I > confusing the > >> > two things here ? > >> > > >> > > >> > I believe all doubts are pointing to the concepts of LOW_MEM and > HIGH_MEM, > >> > but I'm still not being able to wrap my head around them. > >> > > >> > Thanks, > >> > Sunny > >> > > >> > On Thu, Mar 12, 2015 at 11:49 PM, Jeff Haran <[email protected]> > wrote: > >> >> > >> >> -----Original Message----- > >> >> From: [email protected] > >> >> [mailto:[email protected]] On Behalf Of Arun > KS > >> >> Sent: Thursday, March 12, 2015 11:03 AM > >> >> To: Sunny Shah > >> >> Cc: kernelnewbies > >> >> Subject: Re: Understanding the mapping of physical memory to kernel > >> >> address space > >> >> > >> >> Hello Sunny, > >> >> > >> >> On Thu, Mar 12, 2015 at 10:32 PM, Sunny Shah <[email protected] > > > >> >> wrote: > >> >> > Hello, > >> >> > > >> >> > This is my first mail on this list, so please let me know if I'm > erring. > >> >> > > >> >> > I'm reading Bovet and Cesati's "Understanding the Linux Kernel", > >> >> > specifically the chapter "Memory Addressing", sub-section "Kernel > Page > >> >> > Tables". Here they describe how Linux initializes its page tables > for > >> >> > various RAM sizes and how much of the physical address space is > mapped > >> >> > onto the kernel virtual address space. > >> >> > > >> >> > I have several questions from my reading: > >> >> > > >> >> > My understanding is that the 32 bit virtual address space of a > process > >> >> > is split into 2 parts - the first 3 GiB for the user space and the > >> >> > remaining 1GiB for the kernel (with the same kernel mapping being > used > >> >> > for all processes. However, although the kernel is mapped into the > >> >> > higher portion of the address space, it resides in the lower 1 GiB > of > >> >> > RAM. Is this correct? > >> >> Yes. Incase of 3:1 mapping, kernel virtual address starts at > 0xc0000000. > >> >> You can also have 2:2 mappings aswell. It is a configurable option > >> >> > >> >> Just an FYI, I've seen 1:3 mapping too. We had to do that with the > kernels > >> >> we built > >> >> when I was at one company because we needed 3GB of virtual address > space > >> >> to map all > >> >> of the memory mapped registers on their ASICs. > >> >> > >> >> There's lots of options here. > >> >> > >> >> Jeff Haran > >> >> > >> >> > >> > > > > > > >
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
