A process’s memory in swap does not persist after the process quits or crashes.

That is true, but the point is that having swap available, increases the time between recording samples, and needing to commit them to disk.

Well-written, long term recording software doesn’t quit or crash. It records what it needs to record, and - by using swap - gives itself plenty of time to flush the buffers using whatever techniques are necessary for safety.

Disclaimer: I’ve written this software, both with and without swap available in various embedded contexts, in real products. The answer to the question is that having swap means higher data rates can be attained before needing to sync.

▲

robotresearcher 3 days ago | parent [-]

> Well-written, long term recording software doesn’t quit or crash.

Power outages, hardware failures, and OS bugs happen to the finest application software.

I believe you from your experience that it can be useful to have recorded buffers swap out before flushing them to durable storage. But I do find it a bit surprising, since the swap system has to do the storage flush you are paying for the IO, why not do it durably?

The fine article argued that you can save engineer cycles by having the OS manage optimizing out-of-working set memory for you, but that isn’t what you’re arguing here.

I’m interested in understanding your point.

▲

MomsAVoxell 2 days ago | parent [-]

I guess the point is, sometimes you just need a lot of memory and want to record into it as quickly as you can.

Then, when the time is right, flush it all to disk.

The VMM is pretty good at being tight and productive - so use it as the big fat buffer it is, and spawn worker threads to flush things at appropriate times.

If you don't have swap, you have to flush more often ...

	▲	2 days ago \| parent [-]
		[deleted]