diff options
author | Bob Liu <lliubbo@gmail.com> | 2014-02-17 19:11:39 +0800 |
---|---|---|
committer | Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> | 2014-02-28 15:26:12 -0500 |
commit | d4c7abdff73090a98e64d11dada4911ec29bcaea (patch) | |
tree | ec0dc6b7e961b75ce6d603ab798a0fec62d62cbd /drivers/rtc/rtc-max8907.c | |
parent | 6cb606f102e45ea7c42cf3d812883489ba99ce5a (diff) | |
download | talos-obmc-linux-d4c7abdff73090a98e64d11dada4911ec29bcaea.tar.gz talos-obmc-linux-d4c7abdff73090a98e64d11dada4911ec29bcaea.zip |
drivers:xen-selfballoon:reset 'frontswap_inertia_counter' after frontswap_shrink
When I looked at this issue https://lkml.org/lkml/2013/11/21/158, I found that
frontswap_selfshrink() doesn't work as expected sometimes.
Pages are continuously added to frontswap and gotten back soon. It's a waste of
cpu time and increases the memory pressue of Guest OS.
Take an example.
First time in frontswap_selfshrink():
1. last_frontswap_pages = cur_frontswap_pages = 0
2. cur_frontswap_pages = frontswap_curr_pages() = 100
When 'frontswap_inertia_counter' decreased to 0:
1. last_frontswap_pages = cur_frontswap_pages = 100
2. cur_frontswap_pages = frontswap_curr_pages() = 100
3. call frontswap_shrink() and let's assumption that 10 pages are gotten back
from frontswap.
4. now frontswap_curr_pages() is 90.
If then memory is not enough in Guest OS and 9 more pages(smaller than gotten
back) added to frontswap.
Now frontswap_curr_pages() is 99 and we don't expect to get back more pages from
frontswap because geust os is under memory pressure.
But next time in frontswap_selfshrink():
1. last_frontswap_pages is set to the old value of cur_frontswap_pages(still
100)
2. cur_frontswap_pages(99) is still smaller than last_frontswap_pages.
3. call frontswap_shrink() and continue to get back pages from frontswap!!
Signed-off-by: Bob Liu <bob.liu@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Diffstat (limited to 'drivers/rtc/rtc-max8907.c')
0 files changed, 0 insertions, 0 deletions