4 ms·
> This means that, in general, vm.swappiness is simply a ratio of how costly reclaiming and refaulting anonymous memory is compared to file memory for your hard
by tedunangst 2y ago
> This means that, in general, vm.swappiness is simply a ratio of how costly reclaiming and refaulting anonymous memory is compared to file memory for your hardware and workload.
But I think this ignores the likelihood that I want this particular memory reclaimed. It is not equal for files and anon memory. At least on my systems, if anon memory is dirty, it's because I did something with it, and if I haven't freed it, that means I'm still working with it. But there's all sorts of stuff that just kind of ends up in the disk cache, which I will never touch again. It is irrelevant to me that refaulting a swapped anon page is no slower than rereading a file, because the probability that the first will happen is so much greater than the second.
For all that systems try to guess about which pages are in use, or will be used again soon, I find they pretty much all get it wrong and as a result the system gets janky, and it's best to simply weight keeping anon memory in core much higher. I expect disk access to be slow when I read a file. I do not expect ctrl-tab to be slow, ever.
- blauditore 2y agoDo I understand correctly that a low swappiness basically also means higher priority of anon pages over disk caching, simply because the former uses more space and the latter "runs out" eventually? I.e. low swappiness would achieve what you want, sort of?
- Thorrez 2y ago>I do not expect ctrl-tab to be slow, ever. I think ctrl-tab might cause a disk read even without swap, because some/all of the binary of the program you're running might have been evicted from memory (backed by the program file, not swap) and need to get faulted back in when you hit ctrl-tab. The disk read might occur even without eviction, if that part of the program had never been read into memory yet.
- mnw21cam 2y agoYes. Please realise that things that can be evicted from RAM include the code and static data for the programs you are running. If you switch off swap, then you are disqualifying stuff like data pages that a program will set up on process start and then never touch again, which is sometimes a distressingly large amount. That then uses up RAM that could be used to provide a more responsive system. The ideal contents of swap are those data pages that are never going to be touched again. On a normally running system that doesn't have massive memory pressure, that is basically all that will make it into swap, and that's fine because those genuinely are pages that you won't need, and they aren't causing the problems with alt-tab. What probably is causing the problems with alt-tab are one of two possibilities. Either the system is over-burdened and it is having to swap out large amounts of working set (to which the solution is to install more RAM or reduce the load, not switch off swap), or you have been transferring large amounts of data through RAM, causing the disc cache system to evict parts of a program you haven't used for a long time in favour of these files that another program keeps loading in (and switching off swap won't help much with that either, because the system is being quite happy to evict parts of that program that aren't anonymous pages - a solution is to get the program that is handling lots of data to ask the OS kindly not to cache certain things, if it for instance knows that it will only load them once). I do think that Linux's behaviour has improved massively over the last 10 years or so. A lot of these myths about swap were created before the improvements, and we should stop believing them.