[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