public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: David Rientjes <rientjes@google.com>
Cc: menage@google.com, linux-kernel@vger.kernel.org
Subject: Re: [patch] oom: print triggering task's cpuset and mems allowed
Date: Mon, 27 Oct 2008 17:41:36 -0700	[thread overview]
Message-ID: <20081027174136.c97687c7.akpm@linux-foundation.org> (raw)
In-Reply-To: <alpine.DEB.1.10.0810241714290.16902@chino.kir.corp.google.com>

On Fri, 24 Oct 2008 17:15:32 -0700 (PDT)
David Rientjes <rientjes@google.com> wrote:

> +#ifdef CONFIG_CPUSETS
> +#define BUFFER_LEN	(256)
> +
> +static void print_task_cpuset(struct task_struct *p)
> +{
> +	char buffer[BUFFER_LEN];
> +
> +	if (cpuset_get_name(p, BUFFER_LEN, buffer) > 0) {
> +		char nodelist[BUFFER_LEN];
> +
> +		nodelist_scnprintf(nodelist, BUFFER_LEN, p->mems_allowed);
> +		printk(KERN_ERR "%s cpuset=%s mems_allowed=%s\n",
> +		       p->comm, buffer, nodelist);
> +	}
> +}
> +#else
> +static inline void print_task_cpuset(struct task_struct *p)
> +{
> +}
> +#endif
> +
>  /*
>   * Send SIGKILL to the selected  process irrespective of  CAP_SYS_RAW_IO
>   * flag though it's unlikely that  we select a process with CAP_SYS_RAW_IO
> @@ -391,6 +412,7 @@ static int oom_kill_process(struct task_struct *p, gfp_t gfp_mask, int order,
>  		printk(KERN_WARNING "%s invoked oom-killer: "
>  			"gfp_mask=0x%x, order=%d, oomkilladj=%d\n",
>  			current->comm, gfp_mask, order, current->oomkilladj);
> +		print_task_cpuset(current);
>  		dump_stack();
>  		show_mem();
>  		if (sysctl_oom_dump_tasks)

We can call the oom-killer at very very deep nesting levels, and adding
another 512 bytes of stack consuption to that call path is really
risky.  Perhaps use statically allocated buffers protected by a local
spinlock?

Also, 256 bytes might be overkill for storing the cpuset's name?

Also, it's Just Wrong that this code has to hardwire private knowledge
of the max possible length of a cpuset name and of the
nodelist_scnprintf() return string.  These things should be controlled
by a single #define in a shared header file.



  reply	other threads:[~2008-10-28  0:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-25  0:05 [patch] oom: print triggering task's cpuset and mems allowed David Rientjes
2008-10-25  0:15 ` David Rientjes
2008-10-28  0:41   ` Andrew Morton [this message]
2008-10-28 16:08     ` David Rientjes
2008-10-28 21:42       ` Andrew Morton
2008-11-19  1:19       ` Li Zefan
2008-11-19 19:56         ` David Rientjes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081027174136.c97687c7.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=menage@google.com \
    --cc=rientjes@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox