summaryrefslogtreecommitdiffstats
path: root/drivers/atm
diff options
context:
space:
mode:
authorHugh Dickins <hugh@veritas.com>2007-06-27 14:09:53 -0700
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-06-28 11:34:53 -0700
commit30acbabae38793c9c9acace4de5b1c1889570768 (patch)
treec9c1741f04382803475c113865deed065e1ca0cf /drivers/atm
parent172d0496cd22c98ee2e4238821fa309c01685f3a (diff)
downloadop-kernel-dev-30acbabae38793c9c9acace4de5b1c1889570768.zip
op-kernel-dev-30acbabae38793c9c9acace4de5b1c1889570768.tar.gz
mm: kill validate_anon_vma to avoid mapcount BUG
validate_anon_vma gave a useful check on the integrity of the anon_vma list when Andrea was developing obj rmap; but it was not enabled in SLES9 itself, nor in mainline, until Nick changed commented-out RMAP_DEBUG to configurable CONFIG_DEBUG_VM in 2.6.17. Now Petr Vandrovec reports that its BUG_ON(mapcount > 100000) can easily crash a CONFIG_DEBUG_VM=y system. That limit was just an arbitrary number to protect against an infinite loop. We could raise it to something enormous (depending on sizeof struct vma and size of memory?); but I rather think validate_anon_vma has outlived its usefulness, and is better just removed - which gives a magnificent performance boost to anything like Petr's test program ;) Of course, a very long anon_vma list is bad news for preemption latency, and I believe there has been one recent report of such: let's not forget that, but validate_anon_vma only makes it worse not better. Signed-off-by: Hugh Dickins <hugh@veritas.com> Cc: Petr Vandrovec <petr@vmware.com> Acked-by: Nick Piggin <npiggin@suse.de> Cc: Andrea Arcangeli <andrea@suse.de> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'drivers/atm')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud