Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In defence of swap: common misconceptions

chrisdown.name

Post reply on HN
Print view View original

71–80 of 151 posts

Re: In defence of swap: common misconceptions

#71

Post by znep »

Aardwolf wrote: post #38

In defence against swap on my personal computer: -PCs have a lot of RAM now -When you allocate that much memory it's usually a bug in your own code like a size_t that overflowed. I never saw programs I would actually want to use try to allocate that much -When using swap instead of ram, everything becomes so slow that you're screwed anyway. The UI doesn't even respond fast enough to kill whatever tries to use all tha…

The reasons I couldn't live happily without swap on my development machine:

- Macbook Pro's don't have a lot of RAM. Still. (Let's not get into that whole discussion as valid as it may be, that is far from the biggest issue I have with current macbooks...)

- Macbook Pro's have no user facing complexity to use swap or to have it encrypted. Heck, they even give you a middle ground as well by default of compressed RAM.

- I have to run a lot of services to run our development stack. Most of the time I'm only using a few but don't want to have to go manually start and stop services all the time. Also, even within a service typically access to most of the memory isn't required for every request. Swap handles this quite well.

- There are parts of our development stack that, simply put, are extremely bloated in terms of memory use. Four gig webpack process, I'm looking at you. Yup, that is ridiculous and should be fixed and maybe there is a fix out there we haven't figured out ... but I don't care, isn't my problem, and I don't have to fight it because it seldom accesses most of that bloated memory so it lives great in swap.

- I like being able to switch to working on something else without having to shut down and restart all the applications I'm using as required for the new task. Swap is a great fit for that. For example, if I have to switch from developing code to analyzing a large Java heap dump, which requires lots of memory, I don't have to go shut everything down, it just quickly gets paged out to swap and comes back when I need it. I don't care if it takes an extra 30 seconds for switch between these two tasks, it already takes much longer than that to load the heap dump regardless.

I think often people give swap a bad name because they never see what it does well for them unless they go looking for it, they only see it when they are asking their machine to do something where the working set is actually too big for memory and blame swap.

That said, no need for swap if you can live fine without it. I just don't think that is good general advice.

Re: In defence of swap: common misconceptions

#72

Post by quotemstr »

vardump wrote: post #67
_9jgl wrote: post #65

Earlier quoted context omitted.

The issue is that the current OOM killer doesn't support this usage at all. To extend the analogy: what do you do if grandma comes and fills your house with stuff? You need space to work, so you go and drop it off at the self storage place, but what if she just keeps filling your house up? The OOM killer will do absolutely nothing until both your house and the whole self storage place are totally full. By that point,…

Well, just don't allow overcommit, problem solved.

Disallowing overcommit still doesn't solve the whole problem: you can just burn all of RAM and all of swap in commit charge, then swap. Another failure mode is excessive paging IO causing the kernel to spill private memory to the swap file prematurely, preferring instead to fill RAM with dirty disk-backed pages that only later get written out to disk. When your system is in this state, accessing even activity used pages (say, your window manager's heap) might incur be a slow hard fault.

(OSes have gotten a little more resilient against this scenario over the years, but it illustrates the issue.)

Memory pool balancing is a really hard control theory problem! I don't blame some people taking the RAM size efficiency hit and just turning off swap entirely. I just think it's a shame to have to resort to that extreme.

Re: In defence of swap: common misconceptions

#73

Post by vardump »

quotemstr wrote: post #72
vardump wrote: post #67

Earlier quoted context omitted.

Well, just don't allow overcommit, problem solved.

Disallowing overcommit still doesn't solve the whole problem: you can just burn all of RAM and all of swap in commit charge, then swap. Another failure mode is excessive paging IO causing the kernel to spill private memory to the swap file prematurely, preferring instead to fill RAM with dirty disk-backed pages that only later get written out to disk. When your system is in this state, accessing even activity used pa…

I wonder if ARC can be used for replacement policy:

https://en.wikipedia.org/wiki/Adaptive_replacement_cache

Although I guess it's patent encumbered...

Re: In defence of swap: common misconceptions

#74

Post by kartickv »

How long before desktop OSs manage memory like mobile ones, automatically shutting down background apps that aren't being used, so that the system remains responsive no matter what?

Or, worst case, if two tasks that need 8GB each are running on a machine with 8GB memory, kill one, let the other finish, and restart the first one. Or, less ambitious, freeze one, swap it out to disk, let the other finish, and only then resume the frozen app.

Desktop OSs are so primitive at memory management, forcing the complexity onto the user.

Re: In defence of swap: common misconceptions

#75

Post by caf »

wahB4vai wrote: post #20

I'm a big fan of determinism and service uniformity. Having that rarely used and response time critical function/data/whatever swapped out increases service time variation at best and complicates all worst case response time calculations at least. I understand from the land of JIT compilers, garbage collectors, and oversubscribed everything that this is not much of a substantial concern as these features are already…

One of the article's points is that running without swap doesn't necessarily alleviate that. The rarely-used code pages of your rarely-used but response time critical daemon can just as easily be dropped from the page cache and have to be refaulted in from disk, and in fact that's more likely if there isn't swap available to stow the dirty anonymous pages from the cron daemon that wakes up once a day or whatever.

The solution for your rarely-used but response time critical daemon is for it to mlock() its critical data and code pages into memory, which works regardless of whether or not you have swap available. (Or, alternatively, use one of the cgroup controllers that the article alludes to, to give the critical daemon and related processes memory unaffected by memory pressure elsewhere in the system).

Re: In defence of swap: common misconceptions

#76

Post by caf »

avar wrote: post #10

Even for those who understand this well, it's historically been really hard to coerce the Linux kernel into applying the right swap policies to your application. As the author notes much of this has been improve by cgroups, and there's always been big hammers like mlock(), even with those things it can be hard to prevent memory thrashing in extreme cases. I've seen swap disabled completely by people who understood ho…

Swap is only used for anonymous pages (well, and dirty private file pages, which are basically the same thing).

Re: In defence of swap: common misconceptions

#77

Post by kam »

vanni wrote: post #59
cosarara97 wrote: post #36

In my experience, a misbehaving linux system that's out of RAM and has swap to spare will be unusably slow. The process of switching to a tty, logging in, and killing whatever the offending process is can easily take a good 15 minutes. Xorg will just freeze. Oh, and hopefully you know what process it is, else good luck running `top`. Until this is fixed, I'll just keep running my systems with very small amounts of sw…

You can use Alt+SysRq+f to manually call oom_kill.

On many distros, this is disabled by default because there's a chance that the OOM killer will hit something important, like the screen lock. For Ubuntu, enable it in /etc/sysctl.d/10-magic-sysrq.conf.

Re: In defence of swap: common misconceptions

#78

Post by IncRnd »

Symbiote wrote: post #58
IncRnd wrote: post #43

Earlier quoted context omitted.

Exactly! Also, the person who goes from 32G of RAM to 256G of RAM is going to run without swap.

I have 4GiB swapfiles on the cluster nodes I manage, which have 512GiB RAM. It's hardly used, around 300MiB at present, probably things like the mail daemon. It's been useful to have a very slow node, which I can SSH into (after 10 minutes) and kill a chosen process, rather than a dead/OOMed node. But I think the difference is marginal, and perhaps 512MiB would have been a more appropriate size for the partition. (Sw…

We run without swap, and haven't noticed an issue. Did you see any practical benefit to running swap vs not?

Re: In defence of swap: common misconceptions

#79

Post by WalterBright »

quotemstr wrote: post #62

Very few people on this thread read and understood the article. The point isn't working with data sets larger than RAM. The point is making better use of the RAM you do have by taking pages you'll almost never touch and spilling them to disk so that there's more room in RAM for pages you will touch. Banning swap is like making self-storage companies illegal and forcing everyone to hold all possessions in their homes.…

> self storage is plenty useful

With self-storage rising to over $300 per month, it's more cost effective to take the stuff to the dump and buy it again if it is ever needed.

Re: In defence of swap: common misconceptions

#80

Post by black_puppydog »

userbinator wrote: post #70
kzrdude wrote: post #50

Earlier quoted context omitted.

What function does the 0.5GB swap have?

A last-ditch safety buffer, to induce the slowdown so that you'll recognise that RAM is running low and hopefully prevent from actually completely running out.

By that time, my system is usually responding to simple keypresses with latencies >1min... :|
Post reply on HN