Re: Understanding the mapping of physical memory to kernel address space

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

 




On Mar 15, 2015 8:27 PM, "Sunny Shah" <shahsunny715@xxxxxxxxx> 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@xxxxxxxxx> wrote:
>>
>> Hello Sunny,
>>
>> On Sat, Mar 14, 2015 at 8:25 PM, Sunny Shah <shahsunny715@xxxxxxxxx> 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@xxxxxxxxxx> wrote:
>> >>
>> >> -----Original Message-----
>> >> From: kernelnewbies-bounces@xxxxxxxxxxxxxxxxx
>> >> [mailto:kernelnewbies-bounces@xxxxxxxxxxxxxxxxx] 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@xxxxxxxxx>
>> >> 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
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