aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/exported-sql-viewer.py
diff options
context:
space:
mode:
authorLinus Torvalds <[email protected]>2021-07-17 13:27:00 -0700
committerLinus Torvalds <[email protected]>2021-07-17 13:27:00 -0700
commitae14c63a9f20d49dacfb6f3fa3fb11b3b4eb11bf (patch)
tree15f12fd577f83f2d83983320f36b0a6405e9bd5e /tools/perf/scripts/python/exported-sql-viewer.py
parent5d766d55d163a60b709317b15db6c8bb02bf54e4 (diff)
Revert "mm/slub: use stackdepot to save stack trace in objects"
This reverts commit 788691464c29455346dc613a3b43c2fb9e5757a4. It's not clear why, but it causes unexplained problems in entirely unrelated xfs code. The most likely explanation is some slab corruption, possibly triggered due to CONFIG_SLUB_DEBUG_ON. See [1]. It ends up having a few other problems too, like build errors on arch/arc, and Geert reporting it using much more memory on m68k [3] (it probably does so elsewhere too, but it is probably just more noticeable on m68k). The architecture issues (both build and memory use) are likely just because this change effectively force-enabled STACKDEPOT (along with a very bad default value for the stackdepot hash size). But together with the xfs issue, this all smells like "this commit was not ready" to me. Link: https://lore.kernel.org/linux-xfs/[email protected]/ [1] Link: https://lore.kernel.org/lkml/[email protected]/ [2] Link: https://lore.kernel.org/lkml/CAMuHMdW=eoVzM1Re5FVoEN87nKfiLmM2+Ah7eNu2KXEhCvbZyA@mail.gmail.com/ [3] Reported-by: Christoph Hellwig <[email protected]> Reported-by: kernel test robot <[email protected]> Reported-by: Geert Uytterhoeven <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: Randy Dunlap <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/exported-sql-viewer.py')
0 files changed, 0 insertions, 0 deletions