forked from luck/tmp_suning_uos_patched
d4c7abdff7
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> |
||
|---|---|---|
| .. | ||
| events | ||
| xen-pciback | ||
| xenbus | ||
| xenfs | ||
| acpi.c | ||
| balloon.c | ||
| biomerge.c | ||
| cpu_hotplug.c | ||
| dbgp.c | ||
| evtchn.c | ||
| fallback.c | ||
| features.c | ||
| gntalloc.c | ||
| gntdev.c | ||
| grant-table.c | ||
| Kconfig | ||
| Makefile | ||
| manage.c | ||
| mcelog.c | ||
| pci.c | ||
| pcpu.c | ||
| platform-pci.c | ||
| privcmd.c | ||
| privcmd.h | ||
| swiotlb-xen.c | ||
| sys-hypervisor.c | ||
| tmem.c | ||
| xen-acpi-cpuhotplug.c | ||
| xen-acpi-memhotplug.c | ||
| xen-acpi-pad.c | ||
| xen-acpi-processor.c | ||
| xen-balloon.c | ||
| xen-selfballoon.c | ||
| xen-stub.c | ||