public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, randy.dunlap@oracle.com,
	dave@linux.vnet.ibm.com
Subject: Re: [RFC v2][PATCH] dynamically enable readprofile at runtime
Date: Wed, 10 Sep 2008 15:59:56 -0700	[thread overview]
Message-ID: <20080910155956.dce60eb4.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080909180536.9F0C7BAB@kernel>

On Tue, 09 Sep 2008 11:05:36 -0700
Dave Hansen <dave@linux.vnet.ibm.com> wrote:

> 
> Way too often, I have a machine that exhibits some kind of crappy
> behavior.  The CPU looks wedged in the kernel or it is spending
> way too much system time and I wonder what is responsible.
> 
> I try to run readprofile.  But, of course, Ubuntu doesn't enable
> it by default.  Dang!
> 
> The reason we boot-time enable it is that it takes a big bufffer
> that we generally can only bootmem alloc.  But, does it hurt to
> at least try and runtime-alloc it?
> 
> To use:
> echo 2 > /sys/kernel/profile
> 
> Then run readprofile like normal.
> 
> This should fix the compile issue with allmodconfig.  I've
> compile-tested on a bunch more configs now including a few
> more architectures.
> 

Can it be turned off again?  afaict: no?

> +#ifdef CONFIG_PROFILING
> +static ssize_t profiling_show(struct kobject *kobj,
> +				  struct kobj_attribute *attr, char *buf)
> +{
> +	return sprintf(buf, "%d\n", prof_on);
> +}
> +static ssize_t profiling_store(struct kobject *kobj,
> +				   struct kobj_attribute *attr,
> +				   const char *buf, size_t count)
> +{
> +	int ret;
> +
> +	if (prof_on)
> +		return -EEXIST;
> +	/*
> +	 * This eventually calls into get_option() which
> +	 * has a ton of callers and is not const.  It is
> +	 * easiest to cast it away here.
> +	 */
> +	profile_setup((char *)buf);
> +	ret = profile_init();
> +	if (ret)
> +		return ret;
> +	ret = create_proc_profile();
> +	if (ret)
> +		return ret;
> +	return count;
> +}
> +KERNEL_ATTR_RW(profiling);
> +#endif

Tested with CONFIG_SYSFS=n?

> -void __init profile_init(void)
> +int profile_init(void)
>  {
> +	int buffer_bytes;
>  	if (!prof_on)
> -		return;
> +		return 0;
>  
>  	/* only text is profiled */
>  	prof_len = (_etext - _stext) >> prof_shift;
> -	prof_buffer = alloc_bootmem(prof_len*sizeof(atomic_t));
> +	buffer_bytes = prof_len*sizeof(atomic_t);
> +	if (!slab_is_available()) {
> +		prof_buffer = alloc_bootmem(buffer_bytes);
> +		return 0;
> +	}
> +
> +	prof_buffer = kzalloc(buffer_bytes, GFP_KERNEL);
> +	if (prof_buffer)
> +		return 0;
> +
> +	prof_buffer = alloc_pages_exact(buffer_bytes, GFP_KERNEL|__GFP_ZERO);
> +	if (prof_buffer)
> +		return 0;
> +
> +	prof_buffer = vmalloc(buffer_bytes);
> +	if (prof_buffer)
> +		return 0;
> +
> +	return -ENOMEM;
>  }

Well that should cover it.

Did you check to see if any __GFP_NOWARNs are needed there?


alloc_bootmem() will (apparently undocumentedly and secretly) zero the
memory.

kzalloc() will zero the memory.

alloc_pages_exact(__GFP_ZERO) will zero the memory.

But what about vmalloc?  I see no documentation which says that it
zeroes the memory, although it seems that some flavours of it will do
this, but the nommu version does not.  Seems all messed up.


  reply	other threads:[~2008-09-10 23:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-09 18:05 [RFC v2][PATCH] dynamically enable readprofile at runtime Dave Hansen
2008-09-10 22:59 ` Andrew Morton [this message]
2008-09-12 16:55   ` Dave Hansen

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=20080910155956.dce60eb4.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=dave@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=randy.dunlap@oracle.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