Live data from Hacker News

Modernizing Linux swapping: introducing the swap table

lwn.net

21–30 of 132 posts

Re: Modernizing Linux swapping: introducing the swap table

#21
post #16

Earlier quoted context omitted.

Program instructions size is small thus loading is fast, so no need to worry about that too much. I'd look on different things first.

Have you measured this, or is this just an opinion?

Look into /proc//status and /proc//smaps

Re: Modernizing Linux swapping: introducing the swap table

#22

Earlier quoted context omitted.

I dont get why anti-swap is so prevalent in Linux discussions. Like, what does it hurt to stick 8-16-32gb extra "oh fuck" space on your drive. Either you're going to never exhaust your system ram, so it doesn't matter, minimally exhaust it and swap in some peak load but at least nothing goes down, or exhaust it all and start having things get OOM'd which feels bad to me. Am I out of touch? Surely it's the children wh…

The pro-swap stance has never made sense to me because it feels like a logical loop. There’s a common rule of thumb that says you should have swap space equal to some multiple of your RAM. For instance, if I have 8 GB of RAM, people recommend adding 8 GB of swap. But since I like having plenty of memory, I install 16 GB of RAM instead—and yet, people still tell me to use swap. Why? At that point, I already have the s…

This rule of thumb is outdated by two decades.

The proper rule of thumb is to make the swap large enough to keep all inactive anonymous pages after the workload has stabilized, but not too large to cause swap thrashing and a delayed OOM kill if a fast memory leak happens.

Re: Modernizing Linux swapping: introducing the swap table

#23
post #9
post #3

Another useless feature into Linux kernel. Who uses swap space nowadays?! Last time I used swap on Linux device was around Pentium 2 era but in reality closer to 486DX era

You should still use swap. It's not "2x RAM" as advice anymore, and hasn't been for years: https://chrisdown.name/2018/01/02/in-defence-of-swap.html tl;dr; give it 4-8GB and forget about it.

I've heard "square root of physical memory" as a heuristic, although in practice I use less than this with some of my larger systems.

Re: Modernizing Linux swapping: introducing the swap table

#24

One pet peeve I have with virtual memory management on Linux is that, as memory usage approaches 100%, the kernel starts evicting executable pages because technically they're read-only and can be loaded from disk. Thus, the entire system grinds to a halt in a behavior that looks like swapping, because every program that wants to execute instructions has to load its instructions from disk again, only to have those ins…

Is there a way to make linux kernel schedule in a "batch friendly way"? Say I do "make -j" and get 200 gcc processes diong jobserver LTO link with 2GB RSS each. In my head, optimal way through such mess is get as many processes as can fit into RAM without swapping, run them to completion, and schedule additional processes as resources become available. A depth first, "infinite latency" mode.

Any combination of cgroups, /proc flags and other forbidden knobs to get such behaviour?

Re: Modernizing Linux swapping: introducing the swap table

#25
post #23
post #9

Earlier quoted context omitted.

You should still use swap. It's not "2x RAM" as advice anymore, and hasn't been for years: https://chrisdown.name/2018/01/02/in-defence-of-swap.html tl;dr; give it 4-8GB and forget about it.

I've heard "square root of physical memory" as a heuristic, although in practice I use less than this with some of my larger systems.

The proper rule of thumb is to make the swap large enough to keep all inactive anonymous pages after the workload has stabilized, but not too large to cause swap thrashing and a delayed OOM kill if a fast memory leak happens.

Re: Modernizing Linux swapping: introducing the swap table

#27

Earlier quoted context omitted.

It's unloved on Linux because using Linux under memory pressure sucks. But that's not a good reason to abandon improvements. Even more so with the direction RAM prices are headed

It sucks without proper cgroup limits because swap makes OOM slower to trigger. Either set the cgroup limits or make the swap small.

This requires additional setup from the user, the default setup should just "work".

Re: Modernizing Linux swapping: introducing the swap table

#28

Earlier quoted context omitted.

I dont get why anti-swap is so prevalent in Linux discussions. Like, what does it hurt to stick 8-16-32gb extra "oh fuck" space on your drive. Either you're going to never exhaust your system ram, so it doesn't matter, minimally exhaust it and swap in some peak load but at least nothing goes down, or exhaust it all and start having things get OOM'd which feels bad to me. Am I out of touch? Surely it's the children wh…

The pro-swap stance has never made sense to me because it feels like a logical loop. There’s a common rule of thumb that says you should have swap space equal to some multiple of your RAM. For instance, if I have 8 GB of RAM, people recommend adding 8 GB of swap. But since I like having plenty of memory, I install 16 GB of RAM instead—and yet, people still tell me to use swap. Why? At that point, I already have the s…

You're implying that people are telling you to set up swap without any reason, when in fact there are good reasons - namely dealing with memory pressure. Maybe you could fit so much RAM into your computer that you never hit pressure - but why would you do that vs allocating a few GB of disk space for swap?

Also, as has been pointed out by another commenter, 8GB of swap for a system with 8GB of physical memory is overkill.

Re: Modernizing Linux swapping: introducing the swap table

#29

Earlier quoted context omitted.

The pro-swap stance has never made sense to me because it feels like a logical loop. There’s a common rule of thumb that says you should have swap space equal to some multiple of your RAM. For instance, if I have 8 GB of RAM, people recommend adding 8 GB of swap. But since I like having plenty of memory, I install 16 GB of RAM instead—and yet, people still tell me to use swap. Why? At that point, I already have the s…

This rule of thumb is outdated by two decades. The proper rule of thumb is to make the swap large enough to keep all inactive anonymous pages after the workload has stabilized, but not too large to cause swap thrashing and a delayed OOM kill if a fast memory leak happens.

That's not useful as a rule of thumb, since you can't know the size of "all inactive anonymous pages" without doing extensive runtime analysis of the system under consideration. That's pretty much the opposite of what a rule of thumb is for.

Re: Modernizing Linux swapping: introducing the swap table

#30
post #28

Earlier quoted context omitted.

The pro-swap stance has never made sense to me because it feels like a logical loop. There’s a common rule of thumb that says you should have swap space equal to some multiple of your RAM. For instance, if I have 8 GB of RAM, people recommend adding 8 GB of swap. But since I like having plenty of memory, I install 16 GB of RAM instead—and yet, people still tell me to use swap. Why? At that point, I already have the s…

You're implying that people are telling you to set up swap without any reason, when in fact there are good reasons - namely dealing with memory pressure. Maybe you could fit so much RAM into your computer that you never hit pressure - but why would you do that vs allocating a few GB of disk space for swap? Also, as has been pointed out by another commenter, 8GB of swap for a system with 8GB of physical memory is over…

I'm also in the GP's camp; RAM is for volatile data, disk is for data persistence. The first "why would you do that" that needs to be addressed is why volatile data should be written to disk. And "it's just a few % of your disk" is not a sufficient answer to that question.
Post reply on HN