Just for info: On one of my PCs with 32 GiB DDR4, Pop!_OS gives as answer to your
ulimit -l
4100868
while it does not sport inxi, so would have to install inxi before I can share its output.
.
@anon93652015: Swapping is basically a good thing, so nothing to worry if there is more swapping, like your system seems to do.
I did
ulimit --help
this was part of the info
-l the maximum size a process may lock into memory
so it looks like it is reporting a limit to a process not your actual ram.
I know. I was just exaggerating, and I looked up the docs to see how to change things - which I have. Now, I’ll just see if it makes a difference - which I know it may not. Will eventually update the post again with my findings. 
Always good to experiment as long as your system isn’t borked experimenting.
ulimit -l
does not show you how much of your RAM is available, that’s a misunderstanding. It also does not show you how much memory can a process use. What it does show you is how much memory can be locked into RAM, typically using the mlock() syscall, per process for your user.
A process can lock part of its virtual address space into RAM using the aforementioned syscall, and this is the limit. Most of the time, it does not do that, because there is no need to, and there is a performance penalty for unnecessarily locking and unlocking pages. Besides, locking too many pages can decrease the efficiency of swap. So in practice, most of the virtual address space that a program uses remains unlocked.
Locking pages into RAM simply means that the kernel guarantees that those pages will remain in RAM, and will never1 be swapped to the drive, until they are unlocked. Why is this useful? Only in very specific cases. For example, assume you have a cryptographic algorithm running in some process, encrypting or decrypying some data. What you absolutely do not want is the kernel deciding to swap the memory containing secret information to the disk, where it can be reconstructed by some malicious third party. You want that data to remain in RAM at all times, so the program first tells the kernel not to swap those pages – it locks those pages into RAM – and only then it writes sensitive data to them. Also, if some algorithm depends on deterministic timing, the kernel deciding to start swapping in the middle of the algorithm will create a non-deterministic delay and produce wrong results. Again, the solution is locking those pages in RAM.
1 There is one exception that I am aware of (and I’m not a security expert, so there might be others), and that is hybernation, which can be a security risk. A program that writes sensitive data into locked pages also ought to temporarily disable hibernation, otherwise those pages can get written to disk, despite being locked.
In other words, when I do my test, I will see no difference whatsoever. I’ll do it anyway. 
Thanks for the detailed example, though.
Yep. Already took a snapshot before doing it and had a snapshot from -Syu before that, too.
Almost as good as experimenting until you bork it, then restore a snapshot
The only difference here, I guess, is that these particular settings can’t bork your system, just force you to shut it down if things get out of hand.
I did read that your system becomes more vulnerable to hacking with the “wrong settings” though. ← Denial of Service, I think. 
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.