summaryrefslogtreecommitdiffstats
path: root/include/linux
diff options
context:
space:
mode:
authorHugh Dickins <hugh@veritas.com>2008-07-23 21:28:23 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2008-07-24 10:47:21 -0700
commit78ecba081224a2db5876b6b81cfed0b78f58adc7 (patch)
treedb29cc9357ea95172f42e64e833a3a7d3fcfa8fb /include/linux
parent83d1674a946141c3c59d430e96c224f7937e6158 (diff)
downloadop-kernel-dev-78ecba081224a2db5876b6b81cfed0b78f58adc7.zip
op-kernel-dev-78ecba081224a2db5876b6b81cfed0b78f58adc7.tar.gz
mm: fix ever-decreasing swap priority
Vegard Nossum has noticed the ever-decreasing negative priority in a swapon /swapoff loop, which eventually would misprioritize when int wraps positive. Not worth spending much code on, but probably better fixed. It's easy to handle the swapping on and off of just one area, but there's not much point if a pair or more still misbehave. To handle the general case, swapoff should compact negative priorities, keeping them always from -1 to -MAX_SWAPFILES. That's a change, but should cause no regression, since these negative (unspecified) priorities are disjoint from the the positive specified priorities 0 to 32767. One small functional difference, which seems appropriate: when swapoff fails to free all swap from a negative priority area, that area is now reinserted at lowest priority, rather than at its original priority. In moving down swapon's setting of priority, I notice that an area is visible to /proc/swaps when it has swap_map set, yet that was being set before all the visible fields were properly filled in: corrected. Signed-off-by: Hugh Dickins <hugh@veritas.com> Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Reported-by: Vegard Nossum <vegard.nossum@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'include/linux')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud