RFE: Actually use the writeback device

[joebonrichie]

After assigning a writeback device, it is not used unless a command is given to write to it.

# cat /sys/block/zram0/bd_stat 
      0        0       0

Following the upstream documentation: https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html#writeback

If we:

# echo all > /sys/block/zram0/idle
# echo idle > /sys/block/zram0/writeback

Then backing device stats reports

# cat /sys/block/zram0/bd_stat 
      85        0       85

Upstream provides three commands to write to the writeback device.

• Specific pages (for embedded use)
• Huge pages - items that cannot be compressed
• idle pages - items compressed that haven't been used for x amount of time (depends on CONFIG_ZRAM_MEMORY_TRACKING for time granularity)
• Since v5.19 idle+huge - Both huge and idle pages.

For personal computer use probably idle+huge makes the most sense and idle if <5.19.

It would be nice if zram-generator could default to some options and periodically tell zram to write to the the writeback device based on either a timer and/or some simple heuristics.

[nabijaczleweli]

AIUI, and the kernel documentation appears to agree with this, both /idle and /writeback are one-time triggers? So if we did this at set-up time, then we'd mark 0 pages and write 0 pages, right? Which is pretty much what we do now.

[skbeh]

@nabijaczleweli You are right. So if we want to use zram idle pages writeback feature, we need a daemon which automatically marks all pages as idle and flush them later, like this: https://android.googlesource.com/platform/frameworks/base/+/master/services/core/java/com/android/server/ZramWriteback.java Maybe it can be implemented by systemd.timer.

[skbeh]

@joebonrichie They are not options but commands. huge_idle means that the page will be written back only if it is both incompressible and idle.

[joebonrichie]

Thanks, I misunderstood the documentation initially. It looks like systemd timers are the way to go, you may want to check if CONFIG_ZRAM_MEMORY_TRACKING is enabled as well which would allow for additional granularity.

[skbeh]

@joebonrichie If we use timers to mark idle pages and write them back, CONFIG_ZRAM_MEMORY_TRACKING will not make any sense.

[skbeh]

Also, we may need a mechanism to automatically write back huge_idle pages when the system is under memory pressure.

[joebonrichie]

@joebonrichie If we use timers to mark idle pages and write them back, CONFIG_ZRAM_MEMORY_TRACKING will not make any sense.

What i mean is; for example: if a systemd timer is setup to write to the writeback every ten minutes. Without CONFIG_ZRAM_MEMORY_TRACKING enabled you would have to echo all > /sys/block/zram0/idle echo idle > /sys/block/zram0/writeback which would write everything to the writeback even if some of those pages have only been there for a few seconds. However, with CONFIG_ZRAM_MEMORY_TRACKING enabled you could echo 600 > /sys/block/zram0/idle echo idle > /sys/block/zram0/writeback, which would guarantee to only writeback pages that haven't been accessed in 10 minutes.

[skbeh]

@joebonrichie According to the Android implemention, we should have a much long delay after marking and then write back. For example, the Android implemention first marks all pages, delays 24 hours, and then flushes idle pages and marks all pages again, thus it don't need CONFIG_ZRAM_MEMORY_TRACKING. By the way, some Chinese manufacturers are much more aggressive. Their implementions only delays from seconds to minutes, depending on the work load.

[skbeh]

@nabijaczleweli What do you think about this?

[nabijaczleweli]

I agree: this is very work-load dependent, and you can write a timer that matches your work-load. (Frankly, exposing the backing device setup was a bit of a mistake, and pointing it out in the default config more so still.)

[skbeh]

@nabijaczleweli However, the timer can not define a condition that triggers the writeback when a system is under memory pressure (e.g. when available memory is less than 10%).

[nabijaczleweli]

Okay? 9G free is more than fine, so I don't know why you'd want that.

[skbeh]

@nabijaczleweli I mean that if you start an application that occupies a lot of memory, there should be a mechanism to reclaim memory like what zswap does.

[RushingAlien]

Hey i would like to know if my systemd-timer and systemd-service units would work right.

https://github.com/RushingAlien/systemd-zram-writeback