diff options
| author | Chris Wilson <chris@chris-wilson.co.uk> | 2020-04-16 10:35:54 +0100 |
|---|---|---|
| committer | Chris Wilson <chris@chris-wilson.co.uk> | 2020-04-17 11:22:57 +0100 |
| commit | cdb07101dda33e2fcb0f4c2aa199c47159d88f35 (patch) | |
| tree | 97eec1e863aefc2f7b6b9976a5719f446af2501a /runner | |
| parent | 276b8a3f24837e009ff38512f7eeb07029e52616 (diff) | |
runner: More task debug!
In a few cases, we hit a timeout where no process appears to be
deadlocked (i.e. tasks stuck in 'D' with intertwined stacks) but
everything appears to be running happily. Often, they appear to be
fighting over the shrinker, so one naturally presumes we are running low
on memory. But for tests that were designed to run with ample memory to
spare, that is a little disconcerting and I would like to know where the
memory actually went.
sysrq('m'): Will dump current memory info to your console
Sounds like that should do the trick.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Petri Latvala <petri.latvala@intel.com>
Acked-by: Petri Latvala <petri.latvala@intel.com>
Diffstat (limited to 'runner')
| -rw-r--r-- | runner/executor.c | 3 |
1 files changed, 2 insertions, 1 deletions
diff --git a/runner/executor.c b/runner/executor.c index b85cdb44..06390262 100644 --- a/runner/executor.c +++ b/runner/executor.c @@ -702,7 +702,8 @@ static void kmsg_log(int severity, const char *msg) static const char *show_kernel_task_state(const char *msg) { kmsg_log(KMSG_WARN, msg); - sysrq('t'); + sysrq('t'); /* task state, stack traces and cpu run lists */ + sysrq('m'); /* task memory usage */ return msg; } |