mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@infradead.org>
To: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH] Reduce overhead of CONFIG_TIMER_STATS
Date: Mon, 17 Dec 2007 09:03:37 -0800	[thread overview]
Message-ID: <20071217090337.0b1af816@laptopd505.fenrus.org> (raw)
In-Reply-To: <20071216212944.GA5128@ghostprotocols.net>

On Sun, 16 Dec 2007 19:29:44 -0200
Arnaldo Carvalho de Melo <acme@redhat.com> wrote:

> Hi,
> 	While looking at the pahole output for struct timer_list on
> recent kernels I noticed that there is a 4 bytes padding on struct
> timer_list that gets propagated to many structs on 64 bits
> architectures:
> 
> [acme@doppio linux-2.6]$ pahole -C timer_list /tmp/tcp.o.before
> struct timer_list {
>         struct list_head      entry;          /*     0    16 */
>         long unsigned int     expires;        /*    16     8 */
>         void                  (*function)(long unsigned int); /*
> 24     8 */ long unsigned int     data;           /*    32     8 */
>         struct tvec_t_base_s *base;           /*    40     8 */
>         void *                start_site;     /*    48     8 */
>         char                  start_comm[16]; /*    56    16 */
>         /* --- cacheline 1 boundary (64 bytes) was 8 bytes ago --- */
>         int                   start_pid;      /*    72     4 */
> 
>         /* size: 80, cachelines: 2 */
>         /* padding: 4 */
>         /* last cacheline: 16 bytes */
> };
> [acme@doppio linux-2.6]$
> 
> 	So the attached patch reduces the 4 bytes hole overhead of
> CONFIG_TIMER_STATS on 64bit architectures by shrinking the field for
> the process name by 4 bytes.
> 
> 	Statistically this doesn't affects that many process names as
> most are less than 12 bytes. As CONFIG_TIMER_STATS is enabled at least
> on fedora kernels I think that we can, with this patch, still reap the
> benefits of powertopping.

I'm still worried that this means that PowerTOP will end up displaying shortened names..
it's already sometimes tricky to know who's guilty at 16... at 12 I fear it just gets worse.
Isn't there some other reorder that you can do to still get rid of the hole?


-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

  parent reply	other threads:[~2007-12-17 17:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-16 21:29 Arnaldo Carvalho de Melo
2007-12-16 21:39 ` Arnaldo Carvalho de Melo
2007-12-17 17:03 ` Arjan van de Ven [this message]
2007-12-17 19:03   ` Arnaldo Carvalho de Melo

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=20071217090337.0b1af816@laptopd505.fenrus.org \
    --to=arjan@infradead.org \
    --cc=acme@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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

all inboxes | Powered by JetHome®