[igt-dev] [PATCH i-g-t] runner: More task debug!
Petri Latvala
petri.latvala at intel.com
Thu Apr 16 09:48:05 UTC 2020
On Thu, Apr 16, 2020 at 10:39:18AM +0100, Chris Wilson wrote:
> 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 at chris-wilson.co.uk>
> Cc: Petri Latvala <petri.latvala at intel.com>
If indeed 'm' does what you want and not just useless crud like first
two lines of /proc/meminfo,
Acked-by: Petri Latvala <petri.latvala at intel.com>
> ---
> runner/executor.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/runner/executor.c b/runner/executor.c
> index b85cdb448..063902624 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;
> }
> --
> 2.26.0
>
More information about the igt-dev
mailing list