summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/call-graph-from-postgresql.py
diff options
context:
space:
mode:
authorSean Christopherson <seanjc@google.com>2023-07-28 17:47:12 -0700
committerPaolo Bonzini <pbonzini@redhat.com>2023-08-31 13:48:40 -0400
commit350c49fdea222193e886ddfa8cc55989853a05f5 (patch)
tree884d357ab1c66032b5bcaf60374e8275210bada9 /tools/perf/scripts/python/call-graph-from-postgresql.py
parenta98b889492a61a0220f26d8692ec744f1830a172 (diff)
KVM: x86/mmu: Delete rmap_printk() and all its usage
Delete rmap_printk() so that MMU_WARN_ON() and MMU_DEBUG can be morphed into something that can be regularly enabled for debug kernels. The information provided by rmap_printk() isn't all that useful now that the rmap and unsync code is mature, as the prints are simultaneously too verbose (_lots_ of message) and yet not verbose enough to be helpful for debug (most instances print just the SPTE pointer/value, which is rarely sufficient to root cause anything but trivial bugs). Alternatively, rmap_printk() could be reworked to into tracepoints, but it's not clear there is a real need as rmap bugs rarely escape initial development, and when bugs do escape to production, they are often edge cases and/or reside in code that isn't directly related to the rmaps. In other words, the problems with rmap_printk() being unhelpful also apply to tracepoints. And deleting rmap_printk() doesn't preclude adding tracepoints in the future. Link: https://lore.kernel.org/r/20230729004722.1056172-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'tools/perf/scripts/python/call-graph-from-postgresql.py')
0 files changed, 0 insertions, 0 deletions