Workstation tuning params

[Enelar]

Zram device capacity counting in "stored data size". And typical compression size its near 3x. So with old settings, you gave only 11% of your ram. I prefer completely disable hdd/ssd swap, and storing compressed pages 2/3 of my RAM. (factor=200)
Actual ram "wasted" = (RAM * factor / compress_ratio) = 2/3 RAM

But in case of huge overload (when you active using ~ 1.5 of your RAM), threading is a bottleneck. In such moments processes are sleeping, awaiting for data. So i decided to settup 2 compress threads foreach core.

And at last, only one problem remain. Little freeze on swapout. Including mouse lag. It lasts less than half of minute, but still annoying. It happened when "current using application" unable to find free space, but nothing available. And we awaiting for swapout done.
After tuning vfs_cache_pressure we forcing kernel to drop any cache, in such situations. Causing swapout(because memory starvation began), going transparently.

And last of all. We do not want be always in situation of "file cache drop", thats why swappiness is on his maximum. It would trying to get at least few megabytes "trully free" memory. Not data, not cache. Those means that we making little "gap" before cache drop.

So about kernel options: prioritize applications, drop disk cache, and avoid stash write(undropable) disk data.

[Hubbitus]

Will it be merged?

[mystilleef]

Yes, but I need to test it first.

On Mon, Apr 11, 2016, 4:28 PM Pavel Alexeev aka Pahan-Hubbitus <
[email protected]> wrote:

Will it be merged?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#21 (comment)

[Enelar]

It turned to me, that after certain amount of used zram there chance of deadlock, which cause machine stuck. What seems to me, it trying to read data from drive, where no place for file buffers, and they being immediately drop. So we experience linear (or faster) speed reduce, and exponential time of execution.

While it ok for developer's please be aware of such flaw. Currently i am testing other settings, that will improve that by gracefully reducing performance of workstation. (When slowdown becomes noticeable, you probably aggressively user).

To workaround situation: when you noticed that machine stuck once or twice for half an second or more, you on danger. It could handle next 200-400 mb, but if you will open something huge - hard reset.

Or probably you would like to reduce factor up to 150, if you prefer OOM than deadstuck.

[Hubbitus]

@Enelar, about what factor you are speaking?

I also notice such system stuck. Could we try automatically detect such situations?

[Enelar]

@Hubbitus typical, statiscical compression rate for LZO ~27-35%. You should expect reduce factor x3.
1GB of ram compressing into ~370MB of ZRAM.

[zezinho42]

I would not merge such a personal tuning : you change whole system configuration when adding a zram device, this is more than an end user expects. At least, I would only put them as commented values in /etc/sysconfig/zram that each user can activate uncommenting them.
Think about conflicts between /etc/sysctl.conf and this script.

[Enelar]

Yes, of course. Actually after several months of experience, i noticed freezes in several use-cases.
Updated branch. ionice helped me a lot, in heavy OOM situations.