mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Morton" <akpm@linux-foundation.org>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] consolidate WARN_...ONCE() static variables
Date: Wed, 29 Feb 2012 08:21:03 +0000	[thread overview]
Message-ID: <4F4DEDFF02000078000755AB@nat28.tlf.novell.com> (raw)
In-Reply-To: <20120228131936.b565bbcc.akpm@linux-foundation.org>

>>> On 28.02.12 at 22:19, Andrew Morton <akpm@linux-foundation.org> wrote:
> So the idea behind the patch is to use the "unlikely" as a sign that
> the data is rarely touched, so we can move it into its own section to
> prevent it from adding sparseness to data which is more frequently
> touched.
> 
> Correct?  If so, that's key: please copy-n-paste this into the
> changelog.

Done so for the next revision.

>> The space saving results from grouping (many) 1-byte entities
>> together, which (when emitted normally) will generally require
>> padding to 4 or 8 bytes (as being adjacent with other static data
>> in the same or next compilation unit). That padding won't occur
>> if all of the items in a given section are of the same size (and
>> alignment).
> 
> OK.  So the new section should only be used for static bool (or static
> char)?

That's a little too strong, but yes, the change would be less
efficient when objects with an alignment requirement of more than a
byte would get added to that same section.

Avoiding this is difficult though: gcc doesn't allow section name
templates (where e.g. the alignment could be embedded in the
section name by the compiler), nor does it allow any other means
to generate the section name on the fly in all possible cases (it
would only be possible when the object has function scope, as
there we could use an asm() for doing this). And requiring to
_literally_ (i.e. without any alignof() or sizeof()) specify the
respective number would be rather ugly (and calling for mistakes).
I can't think of other alternatives.

Jan


      reply	other threads:[~2012-02-29  8:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-27 15:10 Jan Beulich
2012-02-28  0:03 ` Andrew Morton
2012-02-28  7:41   ` Jan Beulich
2012-02-28  7:44     ` Andrew Morton
2012-02-28  8:02       ` Jan Beulich
2012-02-28  8:12         ` Andrew Morton
2012-02-28  8:16           ` Jan Beulich
2012-02-28  8:32             ` Andrew Morton
2012-02-28  8:58               ` Jan Beulich
2012-02-28 21:19                 ` Andrew Morton
2012-02-29  8:21                   ` Jan Beulich [this message]

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=4F4DEDFF02000078000755AB@nat28.tlf.novell.com \
    --to=jbeulich@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    /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®