Virtual Memory Implementation Issues
Virtual Memory Implementation Issues
Hi, I'm a student in MSc and I'm writing an Essay on the issues that system designers have to face when implementing Virtual Memory Systems. Is this the right place where to ask questions?
Thanks & Regards,
M.
Thanks & Regards,
M.
Re: Virtual Memory Implementation Issues
Hi and Welcome!
Cheers,
Adam
Ask the question and we'll tell you if it's in the right placeIs this the right place where to ask questions?
Cheers,
Adam
Re: Virtual Memory Implementation Issues
Thank you Adam. The fact is that I've just started to prepare for the essay, so I haven't got a question yet However I'm happy that there will be room for my questions here, although I'm not an OS developer (yet!) and I know how appreciated are pertinent and carefully thought questions in this forum!AJ wrote:Hi and Welcome!
Ask the question and we'll tell you if it's in the right placeIs this the right place where to ask questions?
Cheers,
Adam
M.
Re: Virtual Memory Implementation Issues
Is there a performance loss because x68_64 insists on virtual memory? It seems like having an extra level of indirection on all memory accesses would affect performance, wouldn't it? They pipeline instructions and stuff so maybe not.
-
- Member
- Posts: 524
- Joined: Sun Nov 09, 2008 2:55 am
- Location: Pennsylvania, USA
Re: Virtual Memory Implementation Issues
Well the MMU does have to remap virtual addresses to physical ones, but this is probably done without much performance degradation using properly designed circuits. And in most operating systems paging is always used anyway. It probably reduces the amount of transistors needed on the chip as well, because in long mode all addresses can be directly routed to the MMU without worrying about whether paging is enabled or not.
Re: Virtual Memory Implementation Issues
I think Johnny is right. Many if not all of modern multiprogramming OS provide VM paging. As usually happens with caches, the ratio to miss hit/full trip to source justifies the use of these additional layers.JohnnyTheDon wrote:Well the MMU does have to remap virtual addresses to physical ones, but this is probably done without much performance degradation using properly designed circuits. And in most operating systems paging is always used anyway. It probably reduces the amount of transistors needed on the chip as well, because in long mode all addresses can be directly routed to the MMU without worrying about whether paging is enabled or not.
M.
Re: Virtual Memory Implementation Issues
I still wish I could turn it off, momentarily. My kernel and interrupts basically run in physical memory. So, on a interrupt I'd really like to turn off paging for an instant, handle the interrupt, turn paging back on, and return to usermode -- without doing any messing around with CR3, page directories, etc. Unfortunately, Brendan pointed out to me that turning off paging (just for an instant!) invalidates the entire TLB (stupid Intel!). :bigcry:
I can still do a similar thing by using 4M page tables for the kernel/interrupts, and little ones for usermode -- but it's still more of a hassle.
I can still do a similar thing by using 4M page tables for the kernel/interrupts, and little ones for usermode -- but it's still more of a hassle.
-
- Member
- Posts: 524
- Joined: Sun Nov 09, 2008 2:55 am
- Location: Pennsylvania, USA
Re: Virtual Memory Implementation Issues
Well on x86_64 there is a MASSIVE amount of address space, so I just map all physical memory at a certain offset. My kernel and user mode applications run in their virtual address space, but if I need to access memory mapped IO and such I can just add a fixed number to a physical address and turn it into a virtual one.
Re: Virtual Memory Implementation Issues
Yes, but that uses up TLB entries when you access it.
Re: Virtual Memory Implementation Issues
Hi,
Basically, for a decent VMM the optimizations/advantages of paging outweigh the disadvantages and you end up with much better performance (despite the overhead that paging itself causes). However, if a VMM doesn't implement any optimizations, then you'd only get the overhead that paging itself causes, and you end up with worse performance.
Cheers,
Brendan
There is some overhead involved with paging (TLB misses cost some CPU time and paging structures cost some RAM), but there's also optimizations that can be done with paging (avoiding the need to deal with physical RAM fragmentation saves CPU time and so does moving page table entries instead of moving data; there's lots of way to save RAM usage - zeroed page optimizations, shared memory, copy-on-write, etc; and then there's other benefits like it's much easier to implement swap space and memory mapped files in a sane way).LoseThos wrote:Is there a performance loss because x68_64 insists on virtual memory? It seems like having an extra level of indirection on all memory accesses would affect performance, wouldn't it? They pipeline instructions and stuff so maybe not.
Basically, for a decent VMM the optimizations/advantages of paging outweigh the disadvantages and you end up with much better performance (despite the overhead that paging itself causes). However, if a VMM doesn't implement any optimizations, then you'd only get the overhead that paging itself causes, and you end up with worse performance.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.