All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Baron <jbaron@redhat.com>
To: Greg KH <greg@kroah.com>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	joe@perches.com, nick@nick-andrew.net, randy.dunlap@oracle.com
Subject: Re: [PATCH 2/8] dynamic debug - core infrastructure
Date: Fri, 20 Jun 2008 11:38:22 -0400	[thread overview]
Message-ID: <20080620153822.GA10639@redhat.com> (raw)
In-Reply-To: <20080618160812.GB9453@kroah.com>

On Wed, Jun 18, 2008 at 09:08:12AM -0700, Greg KH wrote:
> On Fri, Jun 13, 2008 at 03:00:39PM -0400, Jason Baron wrote:
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -595,6 +595,22 @@ extern const char *dev_driver_string(struct device *dev);
> >  #ifdef DEBUG
> >  #define dev_dbg(dev, format, arg...)		\
> >  	dev_printk(KERN_DEBUG , dev , format , ## arg)
> > +#elif defined(CONFIG_DYNAMIC_PRINTK_DEBUG)
> > +#define dev_dbg(dev, format, ...) do {				    	     \
> > +	static char mod_name[]						     \
> > +	__attribute__((section("__verbose_strings")))			     \
> > +	 = KBUILD_MODNAME;						     \
> > +	static struct mod_debug foobar					     \
> > +	__used								     \
> > +	__attribute__((section("__verbose"), aligned(8))) =		     \
> > +	{ mod_name, mod_name, "0", "0", NULL };				     \
> 
> Does the compiler merge all of these variables together into one within
> the same file?
> 

no.

> If not, should we have a new macro, one per file, for this information?
> 

With this feature enabled, the above 'meta-data' added ~32K to the .init.data
section. This memory is freed when the system boots because it is placed in the
.init.data section. The same is true for modules, the 'meta-data' is freed when
the module loads.

We could reduce the vmlinux by having 'register()' type calls for this
infrastructure, or a new marco per file as you suggest, and i had something
like that in an earlier iteration, but I think the memory savings is very
small when compared to the increased complexity. The simplicity to just put a
'pr_debug()" anywhere and just have it do the right thing is nice.

Also, it should be noted that the total increase in the size of the 'vmlinux' 
was 3%, or 2M, this is due to the above 'meta-data', the new code, and probably 
most significantly, the strings, for the additinal printks. Thus, compressing
the above meta-data, or eliminating it by some other means would only decrease
the size of this infrastructure by 2% or so.

thanks,

-Jason


  reply	other threads:[~2008-06-20 15:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-13 19:00 [PATCH 2/8] dynamic debug - core infrastructure Jason Baron
2008-06-13 22:30 ` Joe Perches
2008-06-16 19:15   ` Jason Baron
2008-06-18 16:08 ` Greg KH
2008-06-20 15:38   ` Jason Baron [this message]
2008-06-21  8:17     ` Greg KH
2008-06-18 20:52 ` Pavel Machek

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=20080620153822.GA10639@redhat.com \
    --to=jbaron@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=greg@kroah.com \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nick@nick-andrew.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.