It seems I was wrong. I did the same test again, and this time even with
more `zram-fraction'. The Darktable memory is compressed, there was no
more hang-up problem. Sorry about the noise, maybe it was a regression
in the old kernel, or my configuration error somewhere.
On 1/12/21 5:55 PM, Mat
Different question: This sounds like you're handling data that won't
fit into RAM+Swap anyway, using zram isn't going to help (or hurt),
because with or without compression, your data just doesn't fit in
memory.
I'm talking about possible outcomes, including the ones I've had.
What does the maxi
Is earlyoom disabled on this system? It should send SIGTERM to
something in this case - which is not the best UX as a hint that an
adjustment needs to be made. But I want to make sure there isn't
something else going wrong.
Yes, it's off. And I have an assumption that earlyoom may not have time
t
Does this reduce your concern?
In a way, yes. Most of the time memory will be compressible, I agree,
but there are non-compressible data, and I'm only concerned about that.
In my opinion, it's better not to set the zram size to 100% for
everyone. Whoever is sure that their data will be compres
I apologize for the possible duplicate message, the past didn't show up
for reasons I don't understand.
I think it's a bad idea. It is better to make `zram-fraction` equal to
0.8 or 0.9, but not 1.0.
For example, if you run Darktable, load a floating-point TIFF image into
it, and try to export
