From: Andrew Morton <akpm@linux-foundation.org>
To: Jan Beulich <JBeulich@suse.com>
Cc: Michal Marek <mmarek@suse.cz>,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] consolidate WARN_...ONCE() static variables
Date: Fri, 6 Jan 2012 03:03:29 -0800 [thread overview]
Message-ID: <20120106030329.d934f5bc.akpm@linux-foundation.org> (raw)
In-Reply-To: <4F06B37D020000780006AC1F@nat28.tlf.novell.com>
On Fri, 06 Jan 2012 07:40:29 +0000 "Jan Beulich" <JBeulich@suse.com> wrote:
> >>> On 05.01.12 at 22:03, Andrew Morton <akpm@linux-foundation.org> wrote:
> > On Thu, 05 Jan 2012 11:09:40 +0000
> > "Jan Beulich" <JBeulich@suse.com> wrote:
> >
> >> >>> On 05.01.12 at 00:03, Andrew Morton <akpm@linux-foundation.org> wrote:
> >> > On Thu, 22 Dec 2011 15:53:49 +0000
> >> > "Jan Beulich" <JBeulich@suse.com> wrote:
> >> >
> >> >> Due to the alignment of following variables, these typically consume
> >> >> more than just the single byte that 'bool' requires, and as there are
> >> >> a few hundred instances, the cache pollution (not so much the waste of
> >> >> memory) sums op. Put these variables into their own section, outside
> >> >> of half way frequently used memory range.
> >> >>
> >>
> >> ...
> >>
> >> > printk_once() should also be converted. And ata_print_version_once(),
> >> > if it insists on continuing to exist.
> >>
> >> I disagree for those (and intentionally didn't touch printk_once();
> >> wasn't aware of the other) - at best this could get marked
> >> __read_mostly, but that's not the subject of this patch.
> >
> > Confused. It is exactly the subject of the patch?
>
> No - the goal here is to eliminate the wasteful alignment holes
> created by the __warned variables in the WARN_...ONCE()
> instances.
What are these alignment holes? I'd assumed (without thinking a lot)
that they were little three or two byte gaps because sizeof(bool)=1 or
2. But I see that sizeof(bool) is actually 4, so I don't know what
you're talking about.
Apparently there is some gcc behaviour which you know about and I
don't.
> These get accessed past and unlikely() condition,
> and hence get moved into a separate data section (so they
> would all end up together, with no holes in between).
>
>
> ...
>
> > I'm suspecting that there is some changelog crappiness going on here.
> > What didn't you tell us?
>
> I think the original description says all that it has to.
If it did that, I wouldn't have had any questions to ask you.
next prev parent reply other threads:[~2012-01-06 10:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-22 15:53 [PATCH] consolidate WARN_...ONCE() static variables Jan Beulich
2011-12-22 17:13 ` Arnaud Lacombe
2011-12-23 7:52 ` Jan Beulich
2012-01-04 23:03 ` Andrew Morton
2012-01-05 11:09 ` Jan Beulich
2012-01-05 21:03 ` Andrew Morton
2012-01-06 7:40 ` Jan Beulich
2012-01-06 11:03 ` Andrew Morton [this message]
2012-01-06 12:38 ` Jan Beulich
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=20120106030329.d934f5bc.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=JBeulich@suse.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mmarek@suse.cz \
/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