3 ms·

Swapping in any form always sucks, period. The machine starts behaving strangely and does not tell you why because it's trying it's hardest to hide the fact tha

Swapping in any form always sucks, period. The machine starts behaving strangely and does not tell you why because it's trying it's hardest to hide the fact that it ran out of resources. Experience has shown me over and over that you just want to feel the limits of the machine hard and fast so you can change what you're asking of it rather than thinking that there is some perf issue or weird bug. It's the idea that swap is somehow useful that's old. It's not, it never worked right for interactive systems. It's a mainframe thing that needs to die.

andrewaylett 2y ago
But where else are you going to put your anonymous pages when you don't want them for a while? Lots of the stuff you're using is backed by disk anyway -- and will be removed from RAM when there's any memory pressure, whether or not you have any swap. If you've got swap then the system can put anonymous pages in it, otherwise it'll need to evict named files more frequently. Unless you have enough RAM that you're literally never evicting anything from your page cache, in which case swap still doesn't hurt you. I'll absolutely agree that swapping out part of the working set is unwanted, but most swapping is benign and genuinely helps performance by allowing the system to retain more useful data in RAM. You don't want to get into a state where you're paging code in and out of RAM because there's nowhere to put data that's not being used.
- speed_spread 2y ago
  The whole concept of "virtual memory" has tainted systems design for decades. Treating RAM as a cache relies on the OS making guesses about what will be needed and what can be passivated without it actually knowing the application requirements. Except that compared to CPU level caching, the cost of page faults is big enough that performance degradation is not linear and breaks the user experience. The idea that a 4GB machine can do the same with as an 8GB one albeit slower is just not true. If you hit the swap, you feel it bad. I'll concede that Zram can work because the degradation is softer. But anything hitting the IO should be explicitly controlled by the app. Other random semi-related thoughts: - Rust having to define a new stdlib to be used in Linux kernel because of explicit allocation failure requirements. Why wasn't this possibility factored in from the beginning? - Most software nowadays just abstracts memory costs, partly explaining why a word processor that used to work fine with 64mb of RAM now takes a gig to get anything done. - Embedded development experience should be a requirement for any serious software engineer.
  - steveklabnik 2y ago
    > Rust having to define a new stdlib to be used in Linux kernel because of explicit allocation failure requirements. This is phrased in a way that’s a bit more extreme than in reality. Some new features are in the process of being added. > Why wasn't this possibility factored in from the beginning? So, there’s a few ways to talk about this. The first is… it was! Rust has three major layers to its standard library: core, alloc, and std. core, the lowest level, is a freestanding library. Alloc introduces memory allocations, and std introduces stuff that builds on top of OS functionality, like filesystems. What’s going on here is the kernel wanting to use the alloc layer in the kernel itself. So it’s naturally a bit higher level, and so needs some more work to fit in. Just normal software development stuff. Why didn’t alloc have fallible APIs? Because of Linux, ironically. The usual setup there means you won’t ever observe an allocation failure. So there hasn’t been a lot of pressure to add those APIs, as they’re less useful then you might imagine at first. And it also goes the other way; a lot of embedded systems do not allocate dynamically at all, so for stuff smaller or lower level than Linux, there hasn’t been any pressure there either. Also, I use the word “pressure” on purpose: like any open source project, work gets done when someone that needs a feature drives that feature forward. These things have been considered, for essentially forever, it’s just that finishing the work was never prioritized by anyone, because there’s an infinite amount of work to do and a finite number of people doing it. The Rust for Linux folks are now those people coming along and driving that upstream work. Which benefits all who come later.
    - speed_spread 2y ago
      Oh hello, thanks for the clarification! Having enjoyed writing some embedded Rust, I'm familiar with the core/alloc/std split. IIUC you're saying that the user-space Linux malloc API itself does not provide a reliable way for the application to think about hard memory limits? Which would fuel my pet theory about "infinite virtual memory" being a significant factor in the ever growing software bloat.
      - steveklabnik 2y ago
        > I'm familiar with the core/alloc/std split. Ah, okay. So yeah, it's not a new standard library, it's "things like Vec are adding .push_within_capacity() that's like push except it returns a Result and errors instead of reallocating" more than "bespoke standard library." > IIUC you're saying that the user-space Linux malloc API itself does not provide a reliable way for the application to think about hard memory limits? It's not the user-space malloc API, it's lower than that. See " /proc/sys/vm/overcommit_memory" in https://man7.org/linux/man-pages/man5/proc_sys_vm.5.html https://man7.org/linux/man-pages/man5/proc_sys_vm.5.html The default is "heuristic overcommit." This page does a better job of explaining what that means: https://www.kernel.org/doc/Documentation/vm/overcommit-accounting https://www.kernel.org/doc/Documentation/vm/overcommit-accou... So, unless you've specifically configured this to 2, there are many circumstances where you simply will not get an error from the kernel, even if you've requested more memory than available. What happens in this case is that your program will continue to run. At some point, it will access the bad allocation. The kernel will notice that there's not actually enough memory, and the "oom killer" will decide to kill a process to make space. It might be your process! It also might not be. Just depends. But this happens later, and asynchronously from your program. You cannot handle this error from inside your program. So even if these APIs existed, they wouldn't change the behavior: they would faithfully report what the kernel reported to them: that the allocation succeeded.
izacus 2y ago
Swapping to zram is just fine and it will improve experience on many machines.
- speed_spread 2y ago
  Yeah, I agree. The memory-to-memory + modern CPU power makes it transparent or at least gives it a soft roll-off that IO based swap never achieves. But it's still a hack which too often is used by manufacturers to cheapen on RAM in machines. As the gas-powered engine people will say: "there's no replacement for displacement" (I wont push the analogy comparing zram to turbocharging but, you know, they both deal with "compression"...)

andrewaylett 2y ago

But where else are you going to put your anonymous pages when you don't want them for a while? Lots of the stuff you're using is backed by disk anyway -- and will be removed from RAM when there's any memory pressure, whether or not you have any swap. If you've got swap then the system can put anonymous pages in it, otherwise it'll need to evict named files more frequently. Unless you have enough RAM that you're literally never evicting anything from your page cache, in which case swap still doesn't hurt you. I'll absolutely agree that swapping out part of the working set is unwanted, but most swapping is benign and genuinely helps performance by allowing the system to retain more useful data in RAM. You don't want to get into a state where you're paging code in and out of RAM because there's nowhere to put data that's not being used.

speed_spread 2y ago
The whole concept of "virtual memory" has tainted systems design for decades. Treating RAM as a cache relies on the OS making guesses about what will be needed and what can be passivated without it actually knowing the application requirements. Except that compared to CPU level caching, the cost of page faults is big enough that performance degradation is not linear and breaks the user experience. The idea that a 4GB machine can do the same with as an 8GB one albeit slower is just not true. If you hit the swap, you feel it bad. I'll concede that Zram can work because the degradation is softer. But anything hitting the IO should be explicitly controlled by the app. Other random semi-related thoughts: - Rust having to define a new stdlib to be used in Linux kernel because of explicit allocation failure requirements. Why wasn't this possibility factored in from the beginning? - Most software nowadays just abstracts memory costs, partly explaining why a word processor that used to work fine with 64mb of RAM now takes a gig to get anything done. - Embedded development experience should be a requirement for any serious software engineer.
- steveklabnik 2y ago
  > Rust having to define a new stdlib to be used in Linux kernel because of explicit allocation failure requirements. This is phrased in a way that’s a bit more extreme than in reality. Some new features are in the process of being added. > Why wasn't this possibility factored in from the beginning? So, there’s a few ways to talk about this. The first is… it was! Rust has three major layers to its standard library: core, alloc, and std. core, the lowest level, is a freestanding library. Alloc introduces memory allocations, and std introduces stuff that builds on top of OS functionality, like filesystems. What’s going on here is the kernel wanting to use the alloc layer in the kernel itself. So it’s naturally a bit higher level, and so needs some more work to fit in. Just normal software development stuff. Why didn’t alloc have fallible APIs? Because of Linux, ironically. The usual setup there means you won’t ever observe an allocation failure. So there hasn’t been a lot of pressure to add those APIs, as they’re less useful then you might imagine at first. And it also goes the other way; a lot of embedded systems do not allocate dynamically at all, so for stuff smaller or lower level than Linux, there hasn’t been any pressure there either. Also, I use the word “pressure” on purpose: like any open source project, work gets done when someone that needs a feature drives that feature forward. These things have been considered, for essentially forever, it’s just that finishing the work was never prioritized by anyone, because there’s an infinite amount of work to do and a finite number of people doing it. The Rust for Linux folks are now those people coming along and driving that upstream work. Which benefits all who come later.
  - speed_spread 2y ago
    Oh hello, thanks for the clarification! Having enjoyed writing some embedded Rust, I'm familiar with the core/alloc/std split. IIUC you're saying that the user-space Linux malloc API itself does not provide a reliable way for the application to think about hard memory limits? Which would fuel my pet theory about "infinite virtual memory" being a significant factor in the ever growing software bloat.
    - steveklabnik 2y ago
      > I'm familiar with the core/alloc/std split. Ah, okay. So yeah, it's not a new standard library, it's "things like Vec are adding .push_within_capacity() that's like push except it returns a Result and errors instead of reallocating" more than "bespoke standard library." > IIUC you're saying that the user-space Linux malloc API itself does not provide a reliable way for the application to think about hard memory limits? It's not the user-space malloc API, it's lower than that. See " /proc/sys/vm/overcommit_memory" in https://man7.org/linux/man-pages/man5/proc_sys_vm.5.html https://man7.org/linux/man-pages/man5/proc_sys_vm.5.html The default is "heuristic overcommit." This page does a better job of explaining what that means: https://www.kernel.org/doc/Documentation/vm/overcommit-accounting https://www.kernel.org/doc/Documentation/vm/overcommit-accou... So, unless you've specifically configured this to 2, there are many circumstances where you simply will not get an error from the kernel, even if you've requested more memory than available. What happens in this case is that your program will continue to run. At some point, it will access the bad allocation. The kernel will notice that there's not actually enough memory, and the "oom killer" will decide to kill a process to make space. It might be your process! It also might not be. Just depends. But this happens later, and asynchronously from your program. You cannot handle this error from inside your program. So even if these APIs existed, they wouldn't change the behavior: they would faithfully report what the kernel reported to them: that the allocation succeeded.

izacus 2y ago

Swapping to zram is just fine and it will improve experience on many machines.

speed_spread 2y ago
Yeah, I agree. The memory-to-memory + modern CPU power makes it transparent or at least gives it a soft roll-off that IO based swap never achieves. But it's still a hack which too often is used by manufacturers to cheapen on RAM in machines. As the gas-powered engine people will say: "there's no replacement for displacement" (I wont push the analogy comparing zram to turbocharging but, you know, they both deal with "compression"...)