A VPN is just a way to say “wrap up my normal internet packets and ship them somewhere specific before they continue the normal way.” The normal way is you want to get a message to some other server, and as a part of setting up the network you’re on, your machine should already have a list of other devices it’s physically connected to (“physically” could be “via radio waves” so not just wired) and they should have already advertised “hey, I’ve got access to these places too” for your information. Your router is likely the only one in your home network advertising anything that is on the larger internet, so all your outgoing messages will have to go that way to get to their destination. For example, I’ve got a phone, a wifi access point, a router, and my ISP’s box; my phone knows the WiFi access point is two hops away from internet because the access point said so, that’s the best one it can see, so it sends it that way and hopes it makes it. Each machine in between does the same thing until hopefully it gets where it is supposed to.
With a VPN, the same messages are wrapped in a second message that is addressed to the other end of the VPN. When it gets to the VPN provider, it’s unwrapped, then the inside message is sent off to wherever it’s supposed to go. If a message comes back to the VPN provider addressed to you (ish, this is simplifying a bit), it’s wrapped up the same way and sent back to you.
Big companies often put resources “behind” the VPN, so you can’t send messages from the outside addresses to the office printer, they’ll get blocked, but you can request a connection to the VPN, and messages that come in through that path do get allowed. The VPN can be one central place where you make sure everything coming in is allowed, then on the other side the security can be a little less tight.
VPNs also encrypt the internal message as a part of wrapping them up, which means that if you’re torrenting via a VPN, all anyone else can see is a message addressed to your VPN provider and then an encrypted message inside. And anyone you were exchanging messages with only ever saw traffic to and from the VPN provider, they never saw where it was going after your VPN provider got it. Only you and the VPN provider know what was happening on both ends, and hopefully they don’t look too closely or keep records.
Hopefully now it’s clear that Mullvad and similar won’t help you access your own things from outside, they’re only good for routing your stuff through them and then out into the rest of the internet. However, this isn’t secret magic tech: you can run your own VPN that goes in the other direction, allowing you into your own home network and then able to connect to things as if you were physically there. Tailscale is probably the easiest thing for things like that nowadays, it’ll set up a whole system where your devices can find each other and set up a mesh of secure, direct connections no matter where they are physically located. By default, just the direct device-to-device connections are re-routed, but you can also make a device an “exit node” that can route all your traffic like a traditional VPN.
Of course, that will be the exact opposite of what you want for privacy while torrenting, as it’s all devices that you clearly own and not hiding their identities whatsoever. But it’s very cool for home networking and self-hosting stuff.
Back in the olden days, if you wrote a program, you were punching machine codes into a punch card and they were being fed into the computer and sent directly to the CPU. The machine was effectively yours while your program ran, then you (or more likely, someone who worked for your company or university) noted your final results, things would be reset, and the next stack of cards would go in.
Once computers got fast enough, though, it was possible to have a program replace the computer operator, an “operating system”, and it could even interleave execution of programs to basically run more than one at the same time. However, now the programs had to share resources, they couldn’t just have the whole computer to themselves. The OS helped manage that, a program now had to ask for memory and the OS would track what was free and what was in use, as well as interleaving programs to take turns running on the CPU. But if a program messed up and wrote to memory that didn’t belong to it, it could screw up someone else’s execution and bring the whole thing crashing down. And in some systems, programs were given a turn to run and then were supposed to return control to the OS after a bit, but it was basically an honor system, and the problem with that is likely clear.
Hardware and OS software added features to enforce more order. OSes got more power, and help from the hardware to wield it. Now instead of asking politely to give back control, the hardware would enforce limits, forcing control back to the OS periodically. And when it came to memory, the OS no longer handed out addresses matching the RAM for the program to use directly, instead it could hand out virtual addresses, with the OS tracking every relationship between the virtual address and the real location of the data, and the hardware providing Memory Management Units that can do things like store tables and do the translation from virtual to physical on its own, and return control to the OS if it doesn’t know.
This allows things like swapping, where a part of memory that isn’t being used can be taken out of RAM and written to disk instead. If the program tries to read an address that was swapped out, the hardware catches that it’s a virtual address that it doesn’t have a mapping for, wrenches control from the program, and instead runs the code that the OS registered for handling memory. The OS can see that this address has been swapped out, swap it back in to real RAM, tell the hardware where it now is, and then control returns to the program. The program’s none the wiser that its data wasn’t there a moment ago, and it all works. If a program messes up and tries to write to an address it doesn’t have, it doesn’t go through because there’s no mapping to a physical address, and the OS can instead tell the program “you have done very bad and unless you were prepared for this, you should probably end yourself” without any harm to others.
Memory is handed out to programs in chunks called “pages”, and the hardware has support for certain page size(s). How big they should be is a matter of tradeoffs; since pages are indivisible, pages that are too big will result in a lot of wasted space (if a program needs 1025 bytes on a 1024-byte page size system, it’ll need 2 pages even though that second page is going to be almost entirely empty), but lots of small pages mean the translation tables have to be bigger to track where everything is, resulting in more overhead.
This is starting to reach the edges of my knowledge, but I believe what this is describing is that RISC-V chips and ARM chips have the ability for the OS to say to the hardware “let’s use bigger pages than normal, up to 64k”, and the Linux kernel is getting enhancements to actually use this functionality, which can come with performance improvements. The MMU can store fewer entries and rely on the OS less, doing more work directly, for example.