OSDev.org

How much would an OS without virtual memory speed up memory accesses?

Can you just define exactly what you mean by "virtual memory"?

iansjack wrote:Can you just define exactly what you mean by "virtual memory"?

Well, I think he means paging.

If the meaning is paging (rather than swapping), there's no answer.

Assuming we are talking about x86 processors (amongst others) then it's a question of whether a non-paged 32-bit system is faster than a paged 64-bit one. It all depends upon the use case. For some uses the restricted RAM means the former doesn't do the job at all. And in other cases you need to balance the cost of TLBs against the expanded, more efficient register set. (Lots of other differences, but let's not make it too complicated.)

My feeling is that, in most cases, a 64-bit OS is going to be faster than a 32-bit one. So the question is not "how much faster is a non-paged OS?" but "Is a non- paged OS ever faster than a paged one?".

If the OP meant swapping, then there is no question - to my mind - that a swapping system is always at least as fast as a non-swapping one, and sometimes infinitely faster. Sometimes the non-swapping one can't handle the workload.

But I'll grant that a non-virtual-memory system (whatever you mean by that term) is likely to be much faster to crash than a virtual-memory system.

It'll make no difference to the speed, I agree. (EDIT: Possibly false, I know nothing about the TLB cache.) It might make a speed difference on processors more primitive than the 486, but I don't think so because even then, memory was struggling to keep up with CPU development. (That's a *very* rough estimate.)

As for crashing, yes, you will have more trouble without swap unless your programs are small and your memory large. In my experience, my first Linux machine had 4MB RAM and 8MB swap. I ran X on this rig and saw segmentation faults frequently. Later, I increased swap to 12MB and the segmentation faults immediately became rare.

Swapping was broken in Plan 9 when 9front forked from it. They considered this all right at first because 1GB is immense compared to the amount of RAM Plan 9 programs use. Later, 9front was used as a webserver and while swap was not the first thing they fixed, they did fix it around this time. An experienced server admin in the chat stated that without swap, you'll be all right most of the time, but when heavy load hits, swap will keep the system going. (I forget the exact details.)

It depends. If you have a mostly flat memory map, then not very much. If you're regularly blowing out of TLB, then maybe a decent amount. It depends entirely on the way the OS's memory model, and the way userspace apps are written.

jamesread wrote:How much would an OS without virtual memory speed up memory accesses?

This is mostly a HW related question. For example ARM has two lines of its CPU the A-line (with MMU) and R (without MMU), the purpose of the R-line is embedded systems where the user cannot change SW or run user added programs. In this case you can remove the MMU and increase the speed of memory accesses. The exact performance gains is hard to tell. You basically have no TLB misses and page table walks anymore which gives a more predictable performance. Also, removing the MMU reduces the power consumption which is often important where you add a Cortex R.

The are of course SW related performance increases as well. Context switches will be faster, no IPC necessary, no access checks and so on.

eekee wrote:An experienced server admin in the chat stated that without swap, you'll be all right most of the time, but when heavy load hits, swap will keep the system going. (I forget the exact details.)

That's absolutely true. We experience this when building LLVM during our nightly Managarm builds. Our build server has more than enough RAM for most of the build but for brief moments, the RAM spikes above 16 GiB. Without swap, we'd have to reduce the number of concurrent compiler invocations to avoid OOM kills (-j in make). Turns out, swapping for these spikes is just much faster than pessimizing the entire build.

eekee wrote:It'll make no difference to the speed, I agree.

Paging is the greatest hit to performance one could ask for! Switching paging tables requires flushing the TLB, which is slooowww.

nexos wrote:Switching paging tables requires flushing the TLB, which is slooowww.

That's not entirely true. You only need to flush the entries for those parts of the page table that have changed.

But which is slower - being forced to use 32-bits only, along with the reduced register set, or invalidating some TLBs?

True, on x86_64 and aarch64, you want to use paging anyway because it enables access to better hardware features. The comparison is more fair (and interesting) on platforms that have otherwise identical 32 and 64 bit ISAs and that do not require paging in 64 bit mode.

I'd guess that most OSs aim to support at least one of those processors.

Yes. I am not even sure if widespread processors exist that fulfill the conditions that I stated above. RISC-V? POWER?

PowerPC64 allows operation in 64-bit real-addressing mode (bypassing all forms of paging), but only in System State. Any operation that changes to Problem State automatically turns on the MMU for data and instructions (those are separate on PPC). It allows you to run without MMU, but also without any form of memory protection, such that processes cannot even opt into any kind of self-protection. At work, we are using OS-9 on PPC32, and OS-9 does not support virtual memory (nor 64-bit operation), but it still runs the MMU (and is identity mapping everything), just to be able to run in Problem State (preventing the execution of privileged instructions) and gain some kind of separation between processes (even though the _os_permit() system call breaks that again, but that is neither here nor there).

The performance benefits of this are dubious. We use a Freescale e300 processor, which has TLB miss interrupts and no automatic page table search. Which is good, since it allows the OS to not use IBM's hashed page table design, but since memory protection is a thing, a TLB miss interrupt handler must still look up if the current context is allowed to access the address it wanted to access, in the way it wanted to access it. So the performance of that depends on the data structure used for the memory protection records. So the whole thing ends up being not a whole lot faster than just supporting normal virtual memory, since the physical address to a given virtual address might be clear, but the access permissions still aren't. Since physical address and access permissions can be squished into the same quantity, looking up one takes as long as looking up the other.

iansjack wrote:

nexos wrote:Switching paging tables requires flushing the TLB, which is slooowww.

That's not entirely true. You only need to flush the entries for those parts of the page table that have changed.

But which is slower - being forced to use 32-bits only, along with the reduced register set, or invalidating some TLBs?

AKAIK, a mov to cr3 invalidates the whole TLB. Correct me if I'm wrong, I've only skimmed the Intel manuals (don't worry, I plan on reading them thoroughly very soon ). As far as reduced register set goes, i386 is just, well, special . Whenever I do anything with ARM, I'm shocked by how may registers there are