Hi Sergio, On Tue, May 14, 2013 at 12:41 AM, Sergio Andrés Gómez del Real < [email protected]> 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 <[email protected]> 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 > > <[email protected]>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 > [email protected] > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
