Understanding the mapping of physical memory to kernel address space

[Sunny Shah]

Thank you so much !!

On Sun, Mar 15, 2015 at 8:48 PM, Arun KS <getarunks at gmail.com> wrote:

>
> On Mar 15, 2015 8:27 PM, "Sunny Shah" <shahsunny715 at gmail.com> 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 <getarunks at gmail.com> wrote:
> >>
> >> Hello Sunny,
> >>
> >> On Sat, Mar 14, 2015 at 8:25 PM, Sunny Shah <shahsunny715 at gmail.com>
> 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 <Jeff.Haran at citrix.com>
> wrote:
> >> >>
> >> >> -----Original Message-----
> >> >> From: kernelnewbies-bounces at kernelnewbies.org
> >> >> [mailto:kernelnewbies-bounces at kernelnewbies.org] 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 <shahsunny715 at gmail.com
> >
> >> >> 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
> >> >>
> >> >>
> >> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150315/1b694479/attachment-0001.html