diff options
| author | Dmitry Vyukov <dvyukov@google.com> | 2021-05-12 10:27:53 +0200 |
|---|---|---|
| committer | Dmitry Vyukov <dvyukov@google.com> | 2021-05-12 11:49:25 +0200 |
| commit | da958a4d24db4dfddd875298efb23733d05272d5 (patch) | |
| tree | 7ea162553072967e54fdbbe6ee495c96682cffac /dashboard/config/linux/bits/linux-next.yml | |
| parent | 29b1aea5e81a42efe6f74558c969c9cfe30a1463 (diff) | |
pkg/report: don't consider handle_mm_fault as anchor frame
We are getting some duplicate reports where the stall actually happens
in some syscall, but the syscall triggers a page fault repeatedly.
As the result we can attribute some of the stalls to the next frame
after handle_mm_fault.
So don't consider handle_mm_fault as an anchor frame.
We need to be careful to not skip entry into page fault
from user space, because that's a completly different case.
In that case the stall is indeed in the page fault handler.
It's also unclear if this is the right thing to do.
If the stall actually happens in the fault handler
and the root cause in the fault handler, then after this change
we will produce duplicate stalls for every place in the kernel
that can trigger a page fault (we will be skipping the handler
itself and attribute it to the innocent caller).
But so far we don't have such examples.
Diffstat (limited to 'dashboard/config/linux/bits/linux-next.yml')
0 files changed, 0 insertions, 0 deletions
