| |
| ▲ | robotresearcher 3 days ago | parent | next [-] | | A process’s memory in swap does not persist after the process quits or crashes. | | |
| ▲ | MomsAVoxell 3 days ago | parent [-] | | 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 ... | | |
|
|
| |
| ▲ | dns_snek 3 days ago | parent | prev [-] | | That's weirdly passive aggressive, swap isn't durable data storage. Reliably recording massive amounts of data for extended periods of time in a studio setting is the most obvious use case for a fixed-size buffer that gets flushed to durable storage at short and predictable time intervals. You wouldn't want a segfault wiping out the entire day's worth of work, would you? | | |
| ▲ | MomsAVoxell 3 days ago | parent [-] | | I didn’t mean to imply that swap was durable data storage. Having swap/more memory available just means you have more buffers before needing to commit and in certain circumstances this can be very beneficial, such as when processing of larger amounts of logged data is needed prior to committing, etc. There is certainly a case for both having and using swap, and disabling it entirely, depending on the data load and realtime needs of the application. Processing data and saving data have different requirements, and the point is really that there is no black and white on this. Use swap if it’s appropriate to the application - don’t use it, if it isn’t. | | |
| ▲ | dns_snek 3 days ago | parent [-] | | I don't really understand what problem you're solving by doing it that way. Instead of storing data (let's call them samples) to durable storage to begin with, you're letting the OS write them to swap which incurs the same cost, but then you need to read them from swap and write them to a different partition again (~triple the original cost). | | |
| ▲ | MomsAVoxell 2 days ago | parent [-] | | Actually the VMM is pretty performant, all things considered. Having more memory, managed for the process by the VMM, means less fuss doing a flush than if you were to memory-constrain things out of the gate. Yes, sometimes, it's perfectly acceptable to flush to disk because you're getting low on RAM. But, on systems with, say .. 4x more swap than physical RAM .. you don't have to do a flush that often - if at all. This is great, for example with high quality audio loads that have to be captured safely over long periods. A system with low RAM and high swap is also a bit more economical, at scale, when building actual hardware in large numbers. So exploiting swap in that circumstance can also effect the BOM costs. |
|
|
|
|
