diff options
author | Sergey Senozhatsky <sergey.senozhatsky@gmail.com> | 2015-09-08 15:04:41 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2015-09-08 15:35:28 -0700 |
commit | ab9d306d9c3bf64b1dbad127aa13252cc550f839 (patch) | |
tree | 525ffb59977b7985b8eecd37109dc3b214d2d77f /mm/swap_cgroup.c | |
parent | 860c707dca155a56dfa115ddd6c00959296144a6 (diff) | |
download | linux-ab9d306d9c3bf64b1dbad127aa13252cc550f839.tar.gz linux-ab9d306d9c3bf64b1dbad127aa13252cc550f839.tar.bz2 linux-ab9d306d9c3bf64b1dbad127aa13252cc550f839.zip |
zsmalloc: use shrinker to trigger auto-compaction
Perform automatic pool compaction by a shrinker when system is getting
tight on memory.
User-space has a very little knowledge regarding zsmalloc fragmentation
and basically has no mechanism to tell whether compaction will result in
any memory gain. Another issue is that user space is not always aware
of the fact that system is getting tight on memory. Which leads to very
uncomfortable scenarios when user space may start issuing compaction
'randomly' or from crontab (for example). Fragmentation is not always
necessarily bad, allocated and unused objects, after all, may be filled
with the data later, w/o the need of allocating a new zspage. On the
other hand, we obviously don't want to waste memory when the system
needs it.
Compaction now has a relatively quick pool scan so we are able to
estimate the number of pages that will be freed easily, which makes it
possible to call this function from a shrinker->count_objects()
callback. We also abort compaction as soon as we detect that we can't
free any pages any more, preventing wasteful objects migrations.
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Suggested-by: Minchan Kim <minchan@kernel.org>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm/swap_cgroup.c')
0 files changed, 0 insertions, 0 deletions