OSDev.org

The Place to Start for Operating System Developers
It is currently Mon Sep 16, 2019 10:10 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: Mapping all PM to VM (long mode).
PostPosted: Fri Jan 21, 2011 4:46 am 
Offline
User avatar

Joined: Sun Nov 22, 2009 11:36 pm
Posts: 13
Is it okay to map all the physical memory to all the process address space? Assume that PM mappings are typed as write back. Suppose a user process request a memory so that kernel would allocate it a memory and it on the process space and return the address of allocation to the caller, also with a type of write back. So there are now 2 different addresses in same space having same PM pointed. Then the user process read that memory, performing a cache line fill. What will happen if a code modifies the data using the PM mappings (instead of using the address being returned upon request), will it still have a write hit (as it has been cached during read) even if they don't have the same virtual address? Also, does mapping the whole PM to VM has a bad performance impact since it would require a lots of translation tables, filling the TLB with useless translation(increasing the tlb miss)?


Top
 Profile  
 
 Post subject: Re: Mapping all PM to VM (long mode).
PostPosted: Fri Jan 21, 2011 1:05 pm 
Offline
Member
Member

Joined: Fri Apr 04, 2008 6:43 am
Posts: 339
Quote:
What will happen if a code modifies the data using the PM mappings (instead of using the address being returned upon request), will it still have a write hit (as it has been cached during read) even if they don't have the same virtual address?


The situation when several linear addresses mapped to same physical is called memory aliasing.
Usually it is used to share R/O data or code between several processes. This way only one physical page could be mapped to several processes.

Answer to your question depends on particual hardware CPU you gonna use. Of the CPU has physically indexed caches no performance penalty will occur.
If the CPU has linearly indexed caches - performance penaly will happen, sometimes even very significant.
Most of the CPUs on the marked have physically indexed caches , not all of them. For example - AMD processors are linearly indexed.

Stanislav


Top
 Profile  
 
 Post subject: Re: Mapping all PM to VM (long mode).
PostPosted: Sat Jan 22, 2011 2:00 pm 
Offline
Member
Member

Joined: Tue Dec 15, 2009 6:36 pm
Posts: 44
stlw wrote:
Quote:
What will happen if a code modifies the data using the PM mappings (instead of using the address being returned upon request), will it still have a write hit (as it has been cached during read) even if they don't have the same virtual address?


Answer to your question depends on particual hardware CPU you gonna use. If the CPU has physically indexed caches no performance penalty will occur.
If the CPU has linearly indexed caches - performance penaly will happen, sometimes even very significant.
Most of the CPUs on the marked have physically indexed caches , not all of them. For example - AMD processors are linearly indexed.


Right. From the software point of view, loads and stores are all matched up using physical addresses. The hardware has to make it right, or it is buggy (these sorts of bugs are probably the most common!)

Of course, it may not be fast...

Even processors with physically indexed caches often use one or two bits of the virtual address. That's why it is best not to alias below, say, 1 MB offset.


Top
 Profile  
 
 Post subject: Re: Mapping all PM to VM (long mode).
PostPosted: Mon Jan 24, 2011 2:55 am 
Offline
User avatar

Joined: Sun Nov 22, 2009 11:36 pm
Posts: 13
so mapping the whole PM is not a good thing?


Top
 Profile  
 
 Post subject: Re: Mapping all PM to VM (long mode).
PostPosted: Tue Jan 25, 2011 6:37 am 
Offline
Member
Member

Joined: Tue Dec 15, 2009 6:36 pm
Posts: 44
You can map all of physical memory, no problem. Just don't map it all with slightly different virtual addresses for different processes.

For example:
kernel gets VM=PM
user gets VM=PM+4K (say to allow for some kernel space)

That would alias every address at the 4K level, which would probably be a huge performance hit.


Top
 Profile  
 
 Post subject: Re: Mapping all PM to VM (long mode).
PostPosted: Wed Jan 26, 2011 12:09 am 
Offline
User avatar

Joined: Sun Nov 22, 2009 11:36 pm
Posts: 13
Quote:
kernel gets VM=PM
user gets VM=PM+4K (say to allow for some kernel space)


What does VM=PM+4K mean? My kernel doesn't have it's own address space. Calling kernel functions is only a matter of jumping from user to kernel(which is in the PM mappings).

Well my purpose for mapping PM to VM is to ease the complexity of the overall system. Here's a sample memory map of my proccess virtual space.
+------------------------+
;------------------------;
;-----USER CODE------;
;-----AND DATA ------;
;------------------------;
;........................; <--128TiB (start of code and data)
; - - - - - - - - - - - - - ;
;-USERMODE SHARED-;
;- LIBRARY/MODULE -;
; - - - - - - - - - - - - - ;
;........................;<--124TiB (start of shared usermode libs)
;~~~~~~~~~~~~~~~~~;
;------------------------;<--MAX_PM (end of PM mapping)
; / / / / / / / / / / /;
; / / / / / / / / / / /;<--16MiB(kernel base)
; / / / / / / / / / / /;
+------------------------+<<--PM is mapped at the bottom of all the process address space)
So, there would be some parts of memory between 0 to
MAX_PM that would be aliased to 124TiB above..
Also, I am using 1GiB pages in mapping the PM, would there be any changes in how cpu cache 1GB pages from 4KB or 2MB pages?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Google [Bot], XenOS and 15 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group