Closed joebonrichie closed 1 year ago
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.
@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
.
@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.
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.
@joebonrichie If we use timers to mark idle pages and write them back, CONFIG_ZRAM_MEMORY_TRACKING
will not make any sense.
Also, we may need a mechanism to automatically write back huge_idle
pages when the system is under memory pressure.
@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.
@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.
@nabijaczleweli What do you think about this?
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.)
@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%).
Okay? 9G free is more than fine, so I don't know why you'd want that.
@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.
Hey i would like to know if my systemd-timer and systemd-service units would work right.
After assigning a writeback device, it is not used unless a command is given to write to it.
Following the upstream documentation: https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html#writeback
If we:
Then backing device stats reports
Upstream provides three commands to write to the writeback device.
CONFIG_ZRAM_MEMORY_TRACKING
for time granularity)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.