diff options
author | Hugh Dickins <[email protected]> | 2019-04-18 17:50:02 -0700 |
---|---|---|
committer | Linus Torvalds <[email protected]> | 2019-04-19 09:46:04 -0700 |
commit | dd862deb151aad2548e72b077a82ad3aa91b715f (patch) | |
tree | d756b2e12e163387da4a07d8c7dc5ab304015ce7 /tools/perf/scripts/python/export-to-postgresql.py | |
parent | 87039546544479d4bedb19d0ea525270c43c1c9b (diff) |
mm: swapoff: remove too limiting SWAP_UNUSE_MAX_TRIES
SWAP_UNUSE_MAX_TRIES 3 appeared to work well in earlier testing, but
further testing has proved it to be a source of unnecessary swapoff
EBUSY failures (which can then be followed by unmount EBUSY failures).
When mmget_not_zero() or shmem's igrab() fails, there is an mm exiting
or inode being evicted, freeing up swap independent of try_to_unuse().
Those typically completed much sooner than the old quadratic swapoff,
but now it's more common that swapoff may need to wait for them.
It's possible to move those cases from init_mm.mmlist and shmem_swaplist
to separate "exiting" swaplists, and try_to_unuse() then wait for those
lists to be emptied; but we've not bothered with that in the past, and
don't want to risk missing some other forgotten case. So just revert to
cycling around until the swap is gone, without any retries limit.
Link: http://lkml.kernel.org/r/[email protected]
Fixes: b56a2d8af914 ("mm: rid swapoff of quadratic complexity")
Signed-off-by: Hugh Dickins <[email protected]>
Cc: "Alex Xu (Hello71)" <[email protected]>
Cc: Huang Ying <[email protected]>
Cc: Kelley Nielsen <[email protected]>
Cc: Konstantin Khlebnikov <[email protected]>
Cc: Rik van Riel <[email protected]>
Cc: Vineeth Pillai <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions