OSDev.org

The Place to Start for Operating System Developers
It is currently Fri Mar 29, 2024 5:23 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 37 posts ]  Go to page 1, 2, 3  Next
Author Message
 Post subject: OS wiith no virtual memory
PostPosted: Sat Dec 19, 2020 11:27 am 
Offline
Member
Member

Joined: Wed Dec 09, 2020 11:32 am
Posts: 49
How much would an OS without virtual memory speed up memory accesses?


Top
 Profile  
 
 Post subject: Re: OS wiith no virtual memory
PostPosted: Sat Dec 19, 2020 12:08 pm 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
Can you just define exactly what you mean by "virtual memory"?


Top
 Profile  
 
 Post subject: Re: OS wiith no virtual memory
PostPosted: Sat Dec 19, 2020 12:33 pm 
Offline
Member
Member

Joined: Fri Nov 22, 2019 5:46 am
Posts: 590
iansjack wrote:
Can you just define exactly what you mean by "virtual memory"?


Well, I think he means paging.


Top
 Profile  
 
 Post subject: Re: OS wiith no virtual memory
PostPosted: Sat Dec 19, 2020 1:07 pm 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
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.


Top
 Profile  
 
 Post subject: Re: OS wiith no virtual memory
PostPosted: Mon Dec 21, 2020 3:35 am 
Offline
Member
Member
User avatar

Joined: Mon May 22, 2017 5:56 am
Posts: 812
Location: Hyperspace
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.)

_________________
Kaph — a modular OS intended to be easy and fun to administer and code for.
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie


Last edited by eekee on Mon Dec 21, 2020 4:06 am, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: OS wiith no virtual memory
PostPosted: Mon Dec 21, 2020 4:00 am 
Offline
Member
Member

Joined: Wed Apr 01, 2020 4:59 pm
Posts: 73
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.


Top
 Profile  
 
 Post subject: Re: OS wiith no virtual memory
PostPosted: Mon Dec 21, 2020 4:36 am 
Offline
Member
Member

Joined: Mon Jul 05, 2010 4:15 pm
Posts: 595
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.


Top
 Profile  
 
 Post subject: Re: OS wiith no virtual memory
PostPosted: Mon Dec 21, 2020 4:47 am 
Offline
Member
Member

Joined: Thu May 17, 2007 1:27 pm
Posts: 999
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.

_________________
managarm: Microkernel-based OS capable of running a Wayland desktop (Discord: https://discord.gg/7WB6Ur3). My OS-dev projects: [mlibc: Portable C library for managarm, qword, Linux, Sigma, ...] [LAI: AML interpreter] [xbstrap: Build system for OS distributions].


Top
 Profile  
 
 Post subject: Re: OS wiith no virtual memory
PostPosted: Mon Dec 21, 2020 7:09 am 
Offline
Member
Member

Joined: Tue Feb 18, 2020 3:29 pm
Posts: 1071
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.

_________________
"How did you do this?"
"It's very simple — you read the protocol and write the code." - Bill Joy
Projects: NexNix | libnex | nnpkg


Top
 Profile  
 
 Post subject: Re: OS wiith no virtual memory
PostPosted: Mon Dec 21, 2020 9:01 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
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?


Top
 Profile  
 
 Post subject: Re: OS wiith no virtual memory
PostPosted: Mon Dec 21, 2020 9:11 am 
Offline
Member
Member

Joined: Thu May 17, 2007 1:27 pm
Posts: 999
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.

_________________
managarm: Microkernel-based OS capable of running a Wayland desktop (Discord: https://discord.gg/7WB6Ur3). My OS-dev projects: [mlibc: Portable C library for managarm, qword, Linux, Sigma, ...] [LAI: AML interpreter] [xbstrap: Build system for OS distributions].


Top
 Profile  
 
 Post subject: Re: OS wiith no virtual memory
PostPosted: Mon Dec 21, 2020 11:19 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
I'd guess that most OSs aim to support at least one of those processors.


Top
 Profile  
 
 Post subject: Re: OS wiith no virtual memory
PostPosted: Mon Dec 21, 2020 11:27 am 
Offline
Member
Member

Joined: Thu May 17, 2007 1:27 pm
Posts: 999
Yes. I am not even sure if widespread processors exist that fulfill the conditions that I stated above. RISC-V? POWER?

_________________
managarm: Microkernel-based OS capable of running a Wayland desktop (Discord: https://discord.gg/7WB6Ur3). My OS-dev projects: [mlibc: Portable C library for managarm, qword, Linux, Sigma, ...] [LAI: AML interpreter] [xbstrap: Build system for OS distributions].


Top
 Profile  
 
 Post subject: Re: OS wiith no virtual memory
PostPosted: Mon Dec 21, 2020 11:47 am 
Offline
Member
Member

Joined: Wed Aug 30, 2017 8:24 am
Posts: 1593
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.

_________________
Carpe diem!


Top
 Profile  
 
 Post subject: Re: OS wiith no virtual memory
PostPosted: Mon Dec 21, 2020 11:51 am 
Offline
Member
Member

Joined: Tue Feb 18, 2020 3:29 pm
Posts: 1071
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

_________________
"How did you do this?"
"It's very simple — you read the protocol and write the code." - Bill Joy
Projects: NexNix | libnex | nnpkg


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 37 posts ]  Go to page 1, 2, 3  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 28 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