[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <4F4DEDFF02000078000755AB@nat28.tlf.novell.com>
Date: Wed, 29 Feb 2012 08:21:03 +0000
From: "Jan Beulich" <JBeulich@...e.com>
To: "Andrew Morton" <akpm@...ux-foundation.org>
Cc: <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] consolidate WARN_...ONCE() static variables
>>> On 28.02.12 at 22:19, Andrew Morton <akpm@...ux-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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists