forked from Minki/linux
a939888ec3
Add a new feature "zram idle/huge page writeback". In the zram-swap use
case, zram usually has many idle/huge swap pages. It's pointless to keep
them in memory (ie, zram).
To solve this problem, this feature introduces idle/huge page writeback to
the backing device so the goal is to save more memory space on embedded
systems.
Normal sequence to use idle/huge page writeback feature is as follows,
while (1) {
# mark allocated zram slot to idle
echo all > /sys/block/zram0/idle
# leave system working for several hours
# Unless there is no access for some blocks on zram,
# they are still IDLE marked pages.
echo "idle" > /sys/block/zram0/writeback
or/and
echo "huge" > /sys/block/zram0/writeback
# write the IDLE or/and huge marked slot into backing device
# and free the memory.
}
Per the discussion at
https://lore.kernel.org/lkml/20181122065926.GG3441@jagdpanzerIV/T/#u,
This patch removes direct incommpressibe page writeback feature
(d2afd25114f4 ("zram: write incompressible pages to backing device")).
Below concerns from Sergey:
== &< ==
"IDLE writeback" is superior to "incompressible writeback".
"incompressible writeback" is completely unpredictable and uncontrollable;
it depens on data patterns and compression algorithms. While "IDLE
writeback" is predictable.
I even suspect, that, *ideally*, we can remove "incompressible writeback".
"IDLE pages" is a super set which also includes "incompressible" pages.
So, technically, we still can do "incompressible writeback" from "IDLE
writeback" path; but a much more reasonable one, based on a page idling
period.
I understand that you want to keep "direct incompressible writeback"
around. ZRAM is especially popular on devices which do suffer from flash
wearout, so I can see "incompressible writeback" path becoming a dead
code, long term.
== &< ==
Below concerns from Minchan:
== &< ==
My concern is if we enable CONFIG_ZRAM_WRITEBACK in this implementation,
both hugepage/idlepage writeck will turn on. However someuser want to
enable only idlepage writeback so we need to introduce turn on/off knob
for hugepage or new CONFIG_ZRAM_IDLEPAGE_WRITEBACK for those usecase. I
don't want to make it complicated *if possible*.
Long term, I imagine we need to make VM aware of new swap hierarchy a
little bit different with as-is. For example, first high priority swap
can return -EIO or -ENOCOMP, swap try to fallback to next lower priority
swap device. With that, hugepage writeback will work tranparently.
So we could regard it as regression because incompressible pages doesn't
go to backing storage automatically. Instead, user should do it via "echo
huge" > /sys/block/zram/writeback" manually.
== &< ==
Link: http://lkml.kernel.org/r/20181127055429.251614-6-minchan@kernel.org
Signed-off-by: Minchan Kim <minchan@kernel.org>
Reviewed-by: Joey Pabalinas <joeypabalinas@gmail.com>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
40 lines
1.4 KiB
Plaintext
40 lines
1.4 KiB
Plaintext
# SPDX-License-Identifier: GPL-2.0
|
|
config ZRAM
|
|
tristate "Compressed RAM block device support"
|
|
depends on BLOCK && SYSFS && ZSMALLOC && CRYPTO
|
|
select CRYPTO_LZO
|
|
help
|
|
Creates virtual block devices called /dev/zramX (X = 0, 1, ...).
|
|
Pages written to these disks are compressed and stored in memory
|
|
itself. These disks allow very fast I/O and compression provides
|
|
good amounts of memory savings.
|
|
|
|
It has several use cases, for example: /tmp storage, use as swap
|
|
disks and maybe many more.
|
|
|
|
See Documentation/blockdev/zram.txt for more information.
|
|
|
|
config ZRAM_WRITEBACK
|
|
bool "Write back incompressible or idle page to backing device"
|
|
depends on ZRAM
|
|
help
|
|
With incompressible page, there is no memory saving to keep it
|
|
in memory. Instead, write it out to backing device.
|
|
For this feature, admin should set up backing device via
|
|
/sys/block/zramX/backing_dev.
|
|
|
|
With /sys/block/zramX/{idle,writeback}, application could ask
|
|
idle page's writeback to the backing device to save in memory.
|
|
|
|
See Documentation/blockdev/zram.txt for more information.
|
|
|
|
config ZRAM_MEMORY_TRACKING
|
|
bool "Track zRam block status"
|
|
depends on ZRAM && DEBUG_FS
|
|
help
|
|
With this feature, admin can track the state of allocated blocks
|
|
of zRAM. Admin could see the information via
|
|
/sys/kernel/debug/zram/zramX/block_state.
|
|
|
|
See Documentation/blockdev/zram.txt for more information.
|