Mapping of ZONE_HIGHMEM in kernel address space in 32bit x86

[Arun KS]

Hi Sergio,

On Tue, May 14, 2013 at 12:41 AM, Sergio Andrés Gómez del Real <
sergio.g.delreal at gmail.com> wrote:

> I've got some questions regarding this linear to physical address
> mapping on x86 architecture; I'm not sure I've grassped the whole
> thing.
> Before asking, I'd like to be sure I understand some basic things about
> this:
>
> 1. Addresses within the kernel are linked to start at 0xC0000000 so,
> that the kernel issues linear addresses starting at gigabyte 3 is
> really accomplished at link time through a linker directive.
> 2. User applications are linked to addresses somewhere at
> 0x00000000-0xBFFFFFFF.
> 3. There is a data structure (struct page), immediately following the
> kernel image in physical memory. It describes all page frames
> available.
> 4. The kernel creates its own page-relative structures. It maps linear
> addresses starting at 0xC0000000 linearly starting at physical address
> 0x00000000. So, accessing this linear space is equivalent to accessing
>

Physical address may not be always 0x0000_0000. It can be mapped any where.


> physical memory, because the map is linear and the conversion between
> linear to physical address is always a constant (0xC0000000)·
> 5. The last part of the kernel's linear address space is reserved for
> temporarily mapping high memory (is this strictly true?).
>
> If all of this is true, here are my questions:
>
> 1. The problem of accessing high memory is EXCLUSIVE to the kernel,
> right? It doesn't affect user-space applications, because it's linear
> address, 0x00000000-0xBFFFFFFF, can be mapped anywhere in physical
> memory, by just writing the high-memory address to the appropiate page
> tables. Is this right?
> 2. When user applications allocates memory, the kernel must allocate
> virtual memory and physical memory, right? For example, the kernel
> would first allocate some linear address from the processes' address
> space, and then find some suitable page frames where to map this
> linear address. It would just write to the appropiate page tables;
> specifically, the page frames can come from low memory or high memory,
> i.e the high memory problem does not affect user-space physical memory
> allocations. Is this entirely correct?
> 3. Is physical memory allocated to user-space generally satisfied from
> high memory?
>
Yes. High mem is the first priority.

thanks,
Arun


> 4. When does the kernel allocate pages from high memory to itself?
>
> Thanks in advance to anyone who replies.
>
> On 5/13/13, Prabhu nath <gprabhunath at gmail.com> wrote:
> > Is this is a question that popped up to your mind arbitrarily or do you
> > have a specific system at hand which triggered you to ponder over the
> > design of the kernel ? I felt the answer to this question is not straight
> > forward but is multi faceted and to be discussed in a specific context.
> >
> >
> > On Sat, May 11, 2013 at 9:02 AM, Paul Davies C
> > <pauldaviesc at gmail.com>wrote:
> >
> >>
> >> In a system with 3:1 split, the ZONE_NORMAL with a size of 896MB is
> >> permanently mapped to the kernel address space.This leaves a 128MB free
> >> space in the Kernel address space and according to my understanding, the
> >> ZONE_HIGHMEM pages are mapped temporarily to this 128MB part. If the
> >> system
> >> actually had a 4GB physical memory you will be mapping(not
> smultaneously)
> >> the HIHGMEM part- which is roughly 3.2GB - to this 128MB part. If that
> >> was
> >> the case Kernel would have to frequently access HIHGMEM which implicates
> >> a
> >> frequent change in temporaty mapping and that in my view is a penalty.
> So
> >> what was the reason why ZONE_NORMAL fixed at 896MB and not something
> >> really
> >> lower?
> >>
> >> --
> >> *Regards,*
> >> *Paul Davies C*
> >> vivafoss.blogspot.com
> >>
> >>
> > --
> > Regards,
> > Prabhunath G
> > Linux Trainer
> > Bangalore
> >
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130514/6c776d18/attachment.html